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Abstract 

This  study  demonstrated  two  approaches  to  improve  current 
software  support  effort  estimation  models  for  aircraft  software.  Both 
approaches  involved  a  functional  orientation  not  used  by  existing  models. 
The  first  approach  demonstrated  how  to  orient  a  model  to  reflect  the  block 
change  cycle  modification  process  and  how  to  represent  support  effort 
changes  over  time  in  order  to  improve  effort  estimation  accuracy.  Current 
software  models  do  not  reflect  the  support  environment  or  the  temporal 
characteristics  of  aircraft  software  support.  The  second  approach 
demonstrated  how  to  calibrate  a  model  by  properly  selecting  source  data  in 
order  to  increase  accuracy.  Support  calibration  is  not  addressed  by  current 
models.  A  literature  search  affirmed  the  validity  of  both  approaches  and 
the  methodology.  In  addition,  a  standard  description  of  the  block  change 
cycle  was  developed  and  validated.  A  prototype  estimation  model  was 
derived  from  the  COCOMO  model  and  included  a  unique  support 
calibration.  Data  was  obtained  from  Air  Force  Software  Support  Centers 
but  was  unusable,  so  data  was  generated  from  the  protot5q)e  for  the 
demonstration.  A  method  that  was  developed  to  compare  the  prototype 
with  current  models  demonstrated  that  the  prototype  is  an  acceptable 
model. 
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DEMONSTRATION  OF  IMPROVED  SOFTWARE 


SUPPORT  LABOR  ESTIMATION  FOR 
Am  FORCE  OPERATIONAL  FUGHT  PROGRAMS  THROUGH 
FUNCTIONAL  ORIENTATION 


1.  Introduction 


Chapter  Overview 

This  thesis  demonstrates  methods  of  improving  existing  software 
support  effort  estimation  models.  This  chapter  begins  with  the  importance 
of  software  support  estimation  in  decision  making.  We  discuss  typical 
effort  estimation  methods  in  current  software  support  estimation  models 
and  the  expected  accuracies  of  those  models  for  Air  Force  software  support 
projects  using  the  block  change  process.  Next,  two  hypotheses  focus  on 
objectives  for  improving  the  accuracy  of  software  support  estimation 
models.  The  scope  of  the  research,  definitions  of  important  concepts,  and  a 
brief  overview  of  the  remaining  chapters  complete  the  Introduction. 

General  Issue 

During  any  phase  of  a  software  project,  decision  makers  must  know 

« 

the  level  of  effort  remaining  for  the  project  in  order  to  make  valid  decisions 
(Lederer:51:  Bourque:  161).  Before  starting  a  software  project,  rational 
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decision  makers  normally  weigh  the  expected  benefits  against  the  expected 
costs.  The  assessment  of  labor  hour  requirements  is  key  to  software 
project  cost  estimates.  A  good  effort  estimate  must  accurately  aggregate 
the  man-months  required  by  specific  skills  into  a  total  project  requirement. 
An  erroneous  effort  estimate  leads  to  an  erroneous  cost  estimate  which,  in 
a  worst  case,  will  lead  to  an  erroneous  start  decision. 

Once  the  project  is  selected,  managers  allocate  resources  to  the 
project  based  on  the  cost  estimate.  This  allocation  directs  how  many 
people  are  hired.  Without  a  good  effort  estimate,  managers  might  hire 
extra  people  and  waste  money  or  hire  too  few  people  and  fall  behind 
schedule.  During  the  project,  managers  must  know  how  much  effort  has 
been  expended  versus  how  much  effort  remains  in  order  to  decide  if  their 
project  is  on  schedule.  Actual  labor  costs  are  accumulated  and  tracked 
against  the  estimated  effort.  An  erroneous  effort  estimate  can  lead  the 
manager  to  an  unrealistic  progress  assessment. 

As  explained  above,  good  effort  estimation  is  essential  to  allow 
management  to  correctly  select,  staff,  and  monitor  software  projects. 
However,  the  pitfalls  associated  with  poor  effort  estimation  are  not  limited 
to  the  development  of  the  software.  Software  support  managers  repeat  the 
selection,  staffing,  and  monitoring  decisions  made  in  development  each 
time  a  change  is  made  to  the  software.  The  impact  of  each  individual 
decision  is  smaller  than  during  development;  however,  the  support  phase 
of  large  software  projects  has  an  interesting  characteristic.  In  large 
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software  projects,  50  -  80%  of  the  life-cycle  cost  occurs  not  during  the 
development  phase  but  during  the  support  phase  (after  the  software 
transfers  to  its  operational  site)  (Banker:!,  DSMC:7-1).  So,  in  terms  of 
cost,  the  support  phase  is  at  least  as  important  as  the  development  phase. 
Since  the  effort  estimate  may  determine  whether  the  project  will  start  at 
all,  managers  should  consider  support  effort  very  early  when  considering 
life  cycle  cost-benefit  trade-offs.  When  predicting  the  cost-worthiness  of  a 
large  software  system,  managers  should  also  focus  on  the  support  of  the 
software,  not  just  the  development. 

In  this  thesis,  we  examine  how  to  improve  the  relationship  between 
computer  software  cost  models  and  the  software  support  environment. 
Although  computer  cost  models  are  commonly  understood,  explaining  our 
interpretation  of  software  support  can  avoid  confusion.  Software  support 
often  is  referred  to  as  software  maintenance,  but  this  thesis  uses  the  term 
software  support  because  "support"  avoids  the  connotation  that 
maintenance  is  only  corrective  (Ferensl:3).  Software  support  encompasses 
more  than  correcting  coding  errors;  it  also  includes  adapting  existing  code 
to  interface  with  new  hardware  and  perfecting  code  beyond  its  original 
capability  (Hager:  1638).  Thus,  the  term  software  support  better  conveys 
the  overall  redevelopment  aspect  of  adapting  and  perfecting  software  as 
well  as  correcting  mistakes. 

Another  potentially  confusing  software  support  term  is  cost.  Cost,  a 
primary  measurement  of  software  support,  is  typically  computed  in  man- 
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months  instead  of  dollars.  Man-months  quantify  the  amount  of  effort 
required  to  complete  a  task  while  avoiding  time-dependent  conversions 
(such  as  inflation)  encountered  when  measuring  cost  in  dollars.  Using 
man-months  does  not  mean  dollar  costs  are  ignored  since,  given  man- 
months,  estimators  can  convert  to  dollars.  Man-months  are  simply  easier 
to  compare  among  differing  projects  and  times.  In  this  thesis,  the  terms 
cost  and  effort  are  synonymous;  both  describe  the  number  of  man-months 
needed  to  accomplish  a  specified  subset  of  the  software  life-cycle  such  as 
one  block  change  during  the  support  phase. 

Typical  Effort  Predicticm  Methods 

Software  managers  use  many  techniques  to  predict  levels  of  effort. 
The  techniques  can  be  grouped  into  three  general  methods:  asking  an 
expert,  comparing  analogous  projects,  and  invoking  a  software  model  (van 
Genuchten:32).  The  expert  method  simply  tasks  very  experienced  software 
analysts  to  predict  the  level  of  effort.  Managers  give  experts  the 
requirements  of  a  system,  and  then  the  experts  wield  their  experience  and 
knowledge  to  forecast  the  cost  of  the  new  system.  The  analogy  method 
estimates  the  cost  of  a  project  by  comparing  the  cost  of  past  projects  to  the 
cost  of  similar  future  projects.  The  implementor  of  this  technique  adjusts 
cost  according  to  differences  between  the  past  and  future  projects.  The 
last  method,  using  a  model,  is  the  least  used  method  (van  Genuchten:37). 
This  method  uses  mathematics  to  predict  the  level  of  effort  for  a  given  set 
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of  input  variables.  The  model  is  found  by  statistically  comparing  known 
project  characteristics  (inputs)  with  known  project  costs  (outputs) 

(Banker:  3).  Assuming  future  costs  come  from  the  same  statistical  process 
as  the  past  costs,  estimators  can  find  future  effort  levels  from  proposed 
project  characteristics.  For  example,  if  given  the  number  of  lines  of  code 
and  the  complexity  of  a  system,  a  software  model,  such  as  the  basic 
COCOMO  model,  can  output  the  man-months  required  to  develop  the 
project  (Boehm;57).  We  will  discuss  the  COCOMO  model  in  Chapter  II. 

The  prime  advantages  of  model  estimators  are  their  objectivity 
(van  Genuchten:40)  and  usability  (Gulezian:235).  A  model  is  objective 
because  it's  a  mathematical  function,  and  a  predefined  function  is  resistant 
to  bias.  Nevertheless,  the  inputs  to  any  function  can  be  selected  in  a 
manner  to  bias  the  final  result.  While  training  and  experience  can  help 
control  this  bias  (Gulezian:42),  models  are  also  helpful  because  the 
required  input  and  the  computation  process  can  be  programmed  into  a 
software  package.  Non-experts  can  then  use  the  software  to  provide  quick 
effort  predictions  and  adjustments. 

Unfortunately,  models  also  have  limitations.  The  biggest 
disadvantage  of  models  is  a  perceived  lack  of  accuracy.  Past  predictions  of 
software  cost  estimates  fi:om  computer  models  indeed  have  been 
inaccurate.  A  thesis  by  a  previous  AFIT  student  (Ourada:1.3), 
conversations  with  current  software  program  mangers,  and  our  personal 


1.5 


experience  confirm  the  poor  performance  of  existing  software  cost 
estimation  models. 

Currently,  the  Air  Force  Cost  Analysis  Agency  recommends  four 
computer  models  for  estimating  software  support  efforts:  1)  the  Software 
Architecture  Sizing  and  Estimating  Tool  (SASET),  2)  the  Software 
Evaluation  and  Estimation  of  Resources  Software  Estimating  Model 
(SEER-SEM),  3)  the  PRICE -SL  Software  Estimating  Model,  and  4)  the 
Revised  Intermediate  Constructive  Cost  Model  (RE VIC)  (Mosemann:2). 
Each  model  employs  statistical  techniques  to  predict  future  software  effort 
based  on  past  efforts.  The  predictive  capability  of  these  models  stems  firom 
the  assumption  that  all  the  data  from  past  projects  come  from  very  similar 
processes.  However,  the  software  engineering  processes  along  with  the 
historical  data  from  those  processes  have  constantly  changed.  Using 
historical  data  from  changing  processes  yields  computer  models  which 
predict  with  high  amounts  of  variability.  This  high  variability 
theoretically  reduces  the  expected  accuracy  of  a  model's  point  estimation  of 
effort.  Any  technique  that  can  reduce  the  variability  of  a  model's 
prediction  can  potentially  increase  the  accuracy  of  the  model's  prediction. 

Specific  IVoblem 

Before  addressing  how  to  increase  model  accuracy,  the  process  by 

* 

which  computer  models  currently  estimate  effort  should  be  addressed.  All 
software  support  effort  estimates  from  computer  models  lie  on  a  continuum 
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between  two  opposing  methods,  parametric  (top-down)  and  detailed 
(bottom-up)  (Stewart:464).  The  heart  of  the  parametric  method  is  a  model 
formed  from  correlating  a  measurable  set  of  software  characteristics  to 
known  levels  of  effort.  Models  based  on  the  parametric  method  use  the 
correlations  to  predict  future  efforts.  Most  current  software  support 
models  tend  to  employ  the  parametric  method. 

The  detailed  method  breaks  down  a  large,  complex  process  into 
small,  simple  steps  and  then  sums  an  estimate  of  each  simple  step  to 
predict  the  effort  of  the  whole  process.  Each  step  should  be  small  enough 
and  simple  enough  to  permit  a  quick,  straightforward  effort  estimate  of 
that  step. 

Estimation  models  need  not  use  the  parametric  or  detailed  methods 
exclusively;  models  can  combine  both  methods.  A  model  could  divide  a 
process  into  a  few  large  subprocesses,  estimate  each  of  these  subprocesses 
by  historical  correlation  (parametrically),  and  then  sum  the  results.  For 
example,  REVIC,  SASET,  and  SEER  divide  the  life  cycle  of  software  into 
two  parts,  initial  development  and  post  deployment  support.  Each  of  these 
models  uses  a  parametric  model  for  development  estimation  and  a  slightly 
different  parametric  model  for  support  estimation.  The  use  of  two  models 
to  estimate  the  software  life  cycle  cost  makes  REVIC,  SASET,  and  SEER 
more  detailed  than  a  single  parametric  model  used  to  describe  total 
software  life  cycle  cost.  However,  the  support  phase  estimates  of  REVIC, 
SASET,  and  SEER  are  purely  parametric. 
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Armed  with  a  basic  understanding  of  the  estimation  process,  we  now 
discuss  how  to  make  the  models  more  accurate.  We  propose  that 
predictive  accuracy  of  the  software  support  models  can  be  increased  by 
functionally  orienting  the  models  to  reduce  the  prediction  variability 
introduced  by  the  model.  Functional  orientation  means  adapting  a  model 
to  better  represent  the  function(s)  of  the  software  and/or  the  software 
support  process.  This  functional  orientation  will  be  demonstrated  in  two 
ways,  one  for  each  type  of  estimation  method. 

The  first  way  to  functionally  orient  a  model  is  to  push  towards  the 
detailed  end  of  the  estimation  continuum.  The  idea  is  to  alter  the  support 
model  to  reflect  the  actual  software  support  process.  We  altered  the 
COCOMO  model  in  a  way  which  better  reflects  the  actual  process  of 
software  support  used  by  the  Air  Force  called  the  block  change  process. 
(The  block  change  process  is  discussed  in  detail  in  the  Definitions  section 
later  in  this  chapter.)  Selecting  the  COCOMO  model  was  the  result  of  two 
considerations.  First,  REVIC,  a  model  on  the  list  of  Air  Force 
recommended  models,  was  derived  from  COCOMO.  Second,  COCOMO 
was  a  well  understood  and  popular  non-proprietary  model  with  good 
documentation.  Therefore,  we  selected  a  baseline  model  familiar  to  Air 
Force  estimators,  thoroughly  researched  the  baseline  model,  legally 
modified  it,  and  then  verified  the  modifications.  Altering  the  COCOMO 
model  encompassed  consolidating  the  published  regulations  and  common 
practices  of  the  Air  Force  Materiel  Command  that  described  the  block 
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change  process.  With  a  simple  model  of  the  block  change  process  in  hand, 
the  next  step  was  to  adapt  this  process  model  to  a  COCOMO  mathematical 
model  to  produce  better  predictions. 

The  second  way  to  functionally  orient  a  model  is  to  keep  the  model 
on  the  parametric  side  of  the  estimation  continuum  but  to  limit  the  scope 
of  the  parametric  correlation.  The  idea  is  to  simply  calibrate  a  model  to  a 
single  functional  area.  The  broadest  functional  area  examined  was  aircraft 
operational  flight  programs  (OFPs).  We  further  divided  OFP  software  into 
five  functional  categories:  communication/identification,  navigation 
sensors,  core  avionics,  electronic  combat,  and  offensive  sensors.  This 
calibration  technique  closely  follows  what  many  software  experts  advise  - 
to  calibrate  the  model  to  the  local  environment  (Boehm:524:  Thibodeau:6- 
6).  Since  the  term  local  environment  is  poorly  defined,  this  thesis 
interpreted  local  environment  as  a  group  of  software  programs  that  are 
functionally  related.  This  interpretation  avoided  the  connotation  of 
environment  as  a  local  geographic  location.  Models  calibrated  to  any  of 
these  subareas  should  predict  better  than  models  calibrated  to  aircraft 
OFPs  or  to  models  calibrated  to  all  types  of  Air  Force  software.  Both 
estimating  approaches,  functional  calibration  for  parametric  models  and 
functional  adaptation  of  more  detailed  models,  reflect  the  basic  engineering 
tenet  that  form  follows  function.  We  adapted  this  tenet  to  the  software 
support  estimation  problem. 
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Hypotheses  &  Ol^ectives 


The  research  hypotheses  and  objectives  are  centered  around  the 
inflight  software  used  aboard  current  Air  Force  aircraft.  The  aircraft  are 
restricted  to  those  with  combat  missions  since  combat  aircraft  have  the 
greatest  variety  of  software  t5rpes. 

Hypothesis  1.  The  functional,  bottom- up  construction  of  a  software 
ei^ort  estimation  model  will  increase  the  predictive  accuracy  of  that  model. 
The  objectives  are  to 

1)  model  the  current  block  change  functional  process  with  simple, 
small  steps. 

2)  program  these  steps  into  a  computer  model  based  upon 
COCOMO. 

3)  demonstrate  the  improved  accuracy  of  bottom-up  modeling. 

4)  find  specific  recommendations  to  tailor  existing  models  for 
functional  adaptation. 

Hypothesis  2‘.  The  functional,  top-down  calibration  of  a 
statistically- based  software  effort  estimation  model  will  improve  the 
predictive  accuracy  of  that  model.  The  objectives  are  to 

1)  demonstrate  the  improved  accuracy  of  functionally  calibrating 
cost  models. 

2)  find  specific  tailoring  recommendations  to  improve  the  accuracy 
of  cost  models. 

The  acceptance  or  rejection  of  these  h}rpotheses  will  not  be  conclusive,  but 
they  should  help  point  the  proper  direction  for  improved  software  support 
cost  estimation. 


*  Data  limitations  hindered  assessment  of  this  hypothesis.  However,  each  objective  is  addressed  to  the  extent 
possible. 
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Soope/Limitation  of  Research 

Our  research  focused  on  estimating  the  main  component  of  software 
support  costs,  man-months  of  effort,  and  not  on  auxiliary  support  costs 
such  as  facilities  or  hardware.  These  auxiliary  costs  are  better  addressed 
outside  effort  estimation  models.  Also,  estimates  for  man-months  of  effort 
on  such  tasks  as  technical  order  changes  and  flight  tests  may  vary 
between  block  changes  and  accuracy  may  vary  accordingly.  However,  the 
proposed  changes  should  increase  accuracy  over  current  models. 

Evaluating  the  h5T)otheses  required  obtaining  data  from  a 
sequential  series  of  block  changes  on  two  different  operational  flight 
programs  from  each  functional  category.  A  time  series  of  actual  data  could 
then  be  used  to  simulate  an  entire  software  support  lifecycle  to  test  the 
predictive  accuracy  of  all  the  models  for  the  entire  software  support  phase 
with  multiple  block  changes.  Both  time  series  and  individual  block  change 
effort  data  could  be  used  to  calibrate  the  models  and  used  to  test  the 
predictive  accuracy  of  all  the  models  for  a  single  block  change  effort. 

The  minimum  set  of  data  sought  for  each  block  change  was  the 
number  of  lines  of  code  changed,  the  time  length  of  the  block  change,  the 
effort  duration  in  man-months,  and  a  description  of  the  code  function 
Other  information,  such  as  available  memory  and  throughput,  could  fulfill 
a  particular  model's  variable  set.  Most  of  the  models  require  these 
additional  variable  values  to  fine  tune  the  estimate;  otherwise,  default 
values  must  be  used.  Once  entered,  these  additional  variables  were  to  be 
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held  constant,  except  in  the  case  of  available  memory  and  throughput. 
Unfortunately,  acceptable  size  data  was  not  available.  The  impact  of  this 
data  unavailability  is  discussed  in  Chapters  III  and  IV. 

The  data  search  was  limited  to  combat  aircraft  (F-111,  F-15,  F-16, 
B-1,  B-52,  E-3,  AC- 130)  that  had  an  established  software  support  history. 
These  aircraft  also  had  subsystems  from  many  of  the  functional  categories. 
Our  search  narrowed  to  these  specific  aircraft  to  focus  on  aircraft  that 
were  likely  to  have  the  data  we  needed.  Although  we  expected  few 
complete  data  sets  to  exist,  we  did  expected  to  find,  at  a  minimum,  enough 
data  to  determine  if  we  were  pointed  in  the  proper  direction. 

Narrowing  the  data  search  to  specific  aircraft  was  consistent  with 
the  focus  of  this  thesis.  After  identifying  a  set  of  Air  Force  software  that 
was  functionally  different  than  other  types  of  Air  Force  software,  we 
further  divided  that  set,  again  based  on  function,  into  subsets.  This  thesis 
is  a  first  cut  at  improving  software  support  estimation.  Future  research 
still  needs  to  be  done  once  actual  data  becomes  available  to  confirm  the 
findings  and  to  determine  at  what  level  of  subdivision  the  proposed 
methods  cease  to  work.  This  work  provides  few  resolute  answers  but, 
instead,  serves  as  a  catalyst  for  future  research. 
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Definitiatis 


Functional  Cat^ories. 

1)  Core  Avionics  (Fire  Control  Computer,  Stores  Management, 
Display  Generation)  that  are  usually  purchased  from  the  airframe 
contractor  as  Contractor  Furnished  Equipment. 

2)  Offensive  Sensors  (Fire-Control  Radar,  Infrared  Search  Track 
sets,  LANTIRN  Targeting  Pod,  PAVE  PENNY  Pod,  PAVE  TAC  Pod, 
AWACs  radar,  JOINT  STARS  radar)  that  may  be  internal  or  external  to 
the  airframe. 

3)  Communication/Identifrcation  Systems  (HAVE  QUICK,  HAVE 
SYNCH,  VHF,  UHF,  IFF,  Integrated  Air  Data  Modem,  etc.)  that  are 
common  across  many  aircraft  types. 

4)  Electronic  Combat  Systems  (Radar  Warning  Receivers, 
Chaff/Flare  Dispensers,  Electronic  Jamming  Systems,  Missile  Warning 
Systems,  etc.)  that  are  added  to  the  aircraft  for  self  protection. 

5)  Navigation  Sensors  (Global  Positioning  System,  Inertial 
Navigation  units,  LANTIRN  Navigation  Pods,  Terrain  Following  Radar, 
Microwave  Landing  System)  that  are  used  for  precision  navigation. 

Block  Change  Paradignx  The  software  support  lifecycle  consists  of  a 
periodic  series  of  redevelopment  blocks  as  governed  by  DoD-STD-2167A 
and  described  by  MIL-HDBK-347.  These  blocks  may  overlap  or  be 
separated  in  time  and  have  the  following  characteristics: 
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1)  Each  block  encompasses  a  mixture  of  support  categories 
(maintenance,  optimization,  adaptation,  new  capability). 

2)  Each  block  may  have  a  fixed  interval,  duration,  budget,  or 
manning  level. 

3)  Each  block  is  either  organic  (Air  Force)  or  contractor  logistic 
support  (CLS)  or  a  mix  of  both. 

4)  Each  block  requires  access  to  non-aircraft  facilities  for 
development  and  test. 

5)  Facility  costs  (development  and  support)  are  part  of  the  life-cycle 
cost  and  are  not  part  of  any  particular  block  change  cost. 

6)  Facility  needs  are  similar  within  functions  and  different  between 
functions. 

7)  Flight  test  costs  for  non-core  avionics  are  budgeted  by  the 
aircraft  and  are  not  part  of  the  change  cost. 

8)  Change  efficiency  may  be  different  for  each  block  change. 

9)  Total  effort  per  block  change  is  a  function  of 

a)  number  of  lines  to  be  changed 

b)  number  of  lines  to  be  added 

c)  number  of  lines  to  be  deleted 

d)  change  complexity 

e)  available  memory  and  throughput 

f)  organization  efficiency 

g)  organization  experience  and  skill  level 

h)  organization  resources 

i)  schedule 

j)  documentation 
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The  actual  process  used  when  a  new  block  change  is  produced  is 
very  similar  to  the  development  of  new  software.  The  biggest  difference 
between  a  new  development  and  a  single  cycle  of  the  block  change  stems 
from  the  starting  point  and  the  requirements  maturity.  A  block  change 
starting  point  is  an  established  software  baseline.  The  starting  point  for  a 
new  development  is  a  requirements  document.  The  requirements  for  the 
block  change  are  problem  reports  and  change  requests  based  on  the  actual 
performance  of  the  software  configuration  and  inherently  different  than 
the  more  abstract  requirements  that  document  new  development  uses. 

These  differences  between  a  new  development  and  a  single  block 
change  result  in  an  additional  process  at  the  start  of  each  block  change. 

In  this  process  the  block  change  requirements  (problem  reports  and  change 
requests)  are  reviewed,  prioritized,  and  approved  by  the  Configuration 
Control  Board  (CCB)  for  incorporation  into  the  software  baseline.  From 
that  point  on,  the  support  process  is  similar  to  a  development  effort.  The 
requirements  are  mapped  into  the  baseline  software,  coded,  tested,  and 
then  released.  After  release,  the  process  may  begin  again. 

Cotnmm  Terms. 

1)  Operational  Flight  Program  (OFF):  Software  written  for  an 
airborne  computer  requiring  real-time  processing,  interaction  with  other 
aircraft  computers,  and  fault  tolerance. 
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2)  Lines  of  Code  (LOG):  Each  OFF  source  instruction  changed, 
added,  or  deleted  in  the  software  update.  This  should  be  counted  in  a 
before  and  after  comparison. 

3)  Software  Support  Activity  (SSA);  the  DoD  or  military  service 
organization  responsible  for  the  software  support  of  designated  computer 
software. 

4)  Software  Support  Product  (SSP):  A  single,  fully  developed, 
tested,  documented,  and  supportable  computer  instruction  set  replicated  in 
sufficient  quantities  and  delivered  to  the  installation  point  (excluding  the 
original  development).  Under  the  block  change  process,  SSP  is  usually 
completed  on  a  periodic  basis. 

5)  Block  Change  Cost  Estimate:  Estimation  of  all  costs  associated 
with  the  production  and  delivery  of  a  single  software  support  product. 

6)  Software  Support  Life  Cycle  Cost  Estimate:  Estimation  of  all 
costs  associated  with  the  production  of  all  software  support  products  for  a 
specific  computer. 

7)  Software  Support  Estimate:  Estimation  of  all  costs  associated 
with  the  production  of  a  single  support  product. 

8)  Bottom-Up  Cost  Estimate  (detailed):  Estimation  method  where 
the  project  is  broken  into  a  number  of  smaller  tasks.  Each  task  is 
estimated  independently  by  analogy,  by  parametric  model,  or  by  best 
engineering  judgement,  and  the  results  are  summed  for  a  project  estimate. 
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9)  Top-Down  Cost  Estimate  (parametric):  Estimation  method  where 
the  project  is  estimated  without  significant  subdivision  of  the  tasks.  The 
common  methods  of  Top-Down  estimation  include  analogy  and  parametric 
models. 

10)  Configuration  Control  Board  (CCB):  An  organization  composed 
of  representatives  from  the  SSA  and  software  users  that  approves  changes 
to  the  configuration  of  designated  computer  software. 

Researdh  Overview 

Chapter  II  presents  a  review  of  available  literature,  regulations,  and 
operating  instructions  pertaining  to  the  Block  Change  Process  and  current 
methods  used  by  Air  Force  organizations  to  estimate  support  costs.  The 
next  chapter  also  reviews  available  literature  and  model  manuals  to 
examine  the  paradigm  that  existing  software  cost  estimation  models  use  to 
estimate  support  costs  and  to  examine  alternatives  to  existing  cost  models. 
Interviews  supplement  the  literature  as  needed.  Chapter  III  addresses  the 
methodology  used  to  build  and  evaluate  the  models  and  the  collection  and 
analysis  of  the  data.  Chapter  IV  is  devoted  to  findings  while  Chapter  V 
contains  our  conclusions  and  recommendations. 
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//.  Literature  Review 


Chapter  Overview 

The  track  record  of  cost  models  to  accxirately  predict  software 
support  cost  is  disappointing.  In  a  1980  study  sponsored  by  the  Air  Force, 
the  Hughes  Aircraft  Company  found  that  none  of  the  current  cost  models 
fulfilled  the  requirement  for  estimating  avionics  embedded  software 
support  costs  (Wainal;27).  In  1991,  Ferens  concluded  that  none  of  the 
eight  cost  models  he  examined  were  shown  to  be  quantitatively  valid 
(Ferensl:!!).  Clearly,  there  is  room  for  improvement  in  software  support 
cost  estimating  models. 

Before  improvement  can  be  made,  a  comprehensive  understanding  of 
the  software  support  cost  estimation  problem  is  needed.  This  literature 
review  investigates  four  areas:  software  support  definition  and  process, 
general  software  cost  estimation  theory,  current  support  model  paradigms, 
and  the  COCOMO/REVIC  software  cost  model.  Each  of  these  areas  form  a 
cornerstone  to  building  better  software  support  estimation  models.  The 
results  of  the  literature  review  are  presented  in  this  chapter. 

Software  Sui^wrt 

Definition.  The  most  relevant  definition  of  software  support  comes 
from  the  Defense  Systems  Management  College  Mission  Critical  Resources 
Management  Guide.  The  term  for  software  support  used  in  the  Guide  is 
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Post  Deployment  Software  Support  (PDSS)  which  has  been  defined  by  the 
Joint  Logistics  Chiefs  (JLC). 

Post  Deployment  Software  Support  is  the  sum  of  all  activities 
required  to  ensure  that,  during  the  production/deployment  phase  of 
a  mission  critical  computer  system’s  life,  the  implemented  and 
fielded  software/system  continues  to  support  its  original  operational 
mission  and  subsequent  mission  modifications  and  production 
improvement  efforts.  (DSMC:7-5) 

Military  Handbook  347,  Mission  Critical  Computer  Resources  Software 
Support,  defines  PDSS  as 

Those  software  support  activities  that  occur  during  the  full-rate 
production  and  initial  deployment  and  operations  support  phases  of 
the  acquisition  process.  (DOD2:8) 

Both  definitions  are  compatible  with  the  software  support  definition 
proposed  in  Chapter  I.  Software  support  is  corrective,  adaptive,  or 
perfective.  The  JLC  definition  makes  additional  allowance  for  changes  due 
to  mission  modifications.  These  changes  are  adaptive  under  the  definition 
scheme  used  in  this  research. 

Barry  Boehm  espouses  the  corrective,  adaptive,  and  perfective 
categories  to  define  support  (Boehm;536).  On  the  other  hand,  John 
Reutter  divides  support  into  seven  categories:  emergency  repairs, 
corrective  coding,  upgrades,  changes  in  conditions,  growth,  enhancements, 
and  support  (DSMC:7-6).  The  seven  categories  may  provide  a  more 
descriptive  categorization  of  the  work,  and  further  investigation  may  prove 
one  categorization  better  than  the  other,  but  such  investigation  becomes 
an  academic  argument.  The  JLC  definition  succinctly  shows  the 


overriding  issue:  software  support  is  the  effort  required  to  make  the 
software  system  continue  to  work  after  it  is  ffelded  in  spite  of  mission 
and/or  hardware  changes.  How  software  support  is  categorized,  except  for 
occurring  before  or  after  fielding,  is  generally  irrelevant  to  the  task  of 
estimating  the  cost  of  the  effort.  Once  the  software  has  been  fielded,  any 
changes  that  follow  are  support  changes  no  matter  what  other 
categorization  is  used. 

Process.  The  usual  process  for  making  DOD  software  support 
changes  is  referred  to  as  the  "block  change".  Under  this  concept,  a  number 
of  changes  are  made  during  one  time  span  and  then  they  are  all  released 
simultaneously  (Ferens3:65).  In  1980,  the  Avionics  Laboratory  of  the 
Wright  Aeronautical  Laboratories  sponsored  the  Hughes  Aircraft  Company 
to  investigate  the  block  change  process  for  aircraft  Operational  Flight 
Programs  (OFPs)  as  part  of  the  Predictive  Software  Cost  Model 
development  (Waina  2).  Hughes  documented  the  support  process  for  the 
A-7,  F-111,  F-16,  F-15,  various  Electronic  Combat  (EC)  equipment,  and 
various  pieces  of  Automated  Test  Equipment  (ATE).  The  process  described 
showed  minor  differences  in  detail  from  aircraft  to  aircraft  and  are  typified 
by  the  F- 16  process. 

The  F- 16  block  change  process,  according  to  the  Hughes  report, 
begins  by  collecting  reports  of  computer  program  deficiencies  and 
descriptions  of  new  capabilities.  The  support  organization  then  prepares 
preliminary  Engineering  Change  Proposals  (ECPs)  for  each  potential 
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change.  Next,  feasibility  studies  and  engineering  tests  are  conducted  to 
better  define  the  change,  and  the  results  are  presented  at  a  Technical 
Conference  (TC).  Members  of  the  TC  establish  priorities,  revise  the 
Preliminary  ECPs  as  necessary,  and  obtain  user  approval.  In  the 
subsequent  step,  software  requirements  are  formulated  and  then  reviewed 
in  a  Preliminary  Design  Review  (PDR).  Programming  and  checkout  occur 
in  the  next  step  culminating  in  a  Critical  Design  Review  (CDR).  After 
CDR,  the  revised  OFP  is  incrementally  tested  ending  with  flight  test.  The 
support  organization  performs  Functional  and  Physical  Configuration 
Audits  at  the  end  of  the  test  phase.  The  software  then  goes  through  a 
Validation  and  Verification  (V  &  V)  process  ending  with  the  release  of  the 
software  to  the  field  (Waina2:344*345).  It  is  interesting  to  note  that  the 
block  change  process  documented  in  the  Hughes  report  has  changed  little 
during  the  past  10  years. 

Several  changes  in  Air  Force  software  regulations  have  occurred 
since  the  Hughes  report  was  written,  most  notably  the  introduction  of 
DoD-STD-2167  in  1985  foUowed  by  DoD-STD-2167A  and  -2168  in  1988 
All  of  these  standards  affect  the  software  documentation,  configuration 
management,  and  quality  programs  of  the  software  developer  and  the 
support  organization.  DoD-STD-2 167A  also  requires  the  CDR  before 
coding  and  adds  a  Test  Readiness  Review  before  testing  (DODlilO). 

Other  process  changes  are  documented  in  MIL-HDBK-347.  This 
handbook  initiates  the  PDSS  process  with  the  submittal  of  a 
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problem/change  request  and  then  sequences  four  major  phases:  initial 
analysis,  software  development,  system  integration  and  testing,  and  lastly 
product  logistics  (DOD2:25).  Spanning  these  phases  is  the  continuous 
activity  of  support  operations  and  maintenance.  The  final  product  of  the 
'  process  is  a  delivery  package. 

A  more  detailed  description  of  the  PDSS  process  would  label  the 
problem/change  report  as  the  name  applied  to  any  form  that  reports 
software  problems  or  proposes  software  enhancements.  For  each  report 
during  the  initial  analysis  phases,  the  software  support  activity  (SSA) 
collects  all  necessary  decision-making  information  including  change 
classification,  impact  analysis,  estimated  effort,  and  risk  identification. 

The  Configuration  Control  Board  (CCB)  then  examines  this  initial  analysis 
and  decides  if  the  proposed  changes  should  be  implemented.  The 
development  phase  accepts  the  initial  analysis  as  a  starting  requirement 
and  proceeds  to  develop  the  change  until  the  modified  software  is  ready  for 
testing.  During  system  integration  and  test,  the  SSA  incrementally  tests 
the  system  until  the  software  performs  acceptably  on  real-time  hardware 
in  a  realistic  operational  environment.  Faults  are  identified,  isolated,  and 
then  corrected  throughout  testing.  Finally,  the  SSA  reproduces  and 
^  verifies  the  final  delivery  packages,  delivers  them  to  the  users,  trains  the 

Y  users  on  the  new  changes,  and  may  even  install  and  check  out  the  updated 

software.  Throughout  the  entire  PDSS  process,  support  operations  and 
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maintenance  activities  provide  the  overhead  structure  necessary  to  keep 
the  SSA  functioning  smoothly. 

It  is  interesting  to  note  that  the  processes  described  by  Hughes, 
DoD-STD-2 167A,  and  MIL-HDBK-347  differ  in  only  minor  degrees. 
Although  the  PDSS  process  may  require  a  few  unique  activities  such  as 
final  package  delivery  and  training,  all  the  above  processes  are  more 
similar  than  dissimilar.  The  support  process  descriptions  demonstrate 
that  the  phrase  "re-development”  is  an  apt  label  for  the  PDSS  cornerstone 
of  the  software  support  estimation.  In  fact,  MIL-HDBK-347  explicitly  cites 
the  PDSS  software  development  phase  as  following  a  DoD-STD-2167A 
development  cycle  (DOD2:25). 

General  Software  Cost  Estimation  Theory 

To  aid  understanding  of  the  second  cornerstone  of  software  support 
estimation,  general  software  cost  estimation  theory,  an  optimal  software 
support  estimation  tool  based  on  the  available  literature  was  synthesized. 
The  first  step  was  to  define  the  characteristics  of  an  optimal  tool  and 
identify  what  parameters  were  necessary  for  the  tool  to  estimate  effort 
accurately.  The  next  step  was  to  investigate  the  parameters  themselves  to 
understand  their  expected  behavior  over  time  and  to  understand  their 
interactions  with  each  other.  The  following  section  reviews  the  results. 

Optimal  Tool.  An  ideal  software  estimation  tool  would  accept  some 
number  of  known  block  change  efforts  along  with  their  production 
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characteristics  and  would  contain  a  regression  relationship  that  could  be 
used  to  predict  future  efforts.  The  production  characteristics  would  be 
easily  observable  and  would  have  been  recorded  along  with  the  original 
data.  The  most  likely  factors  to  be  correlated  are  magnitude  of  effort 
(expressed  in  man-months)  and  the  size  of  the  product  (expressed  in  LOG). 
Given  a  set  of  expected  lines  of  code  and  production  characteristics,  the 
tool  could  find  an  estimate  of  the  effort  required.  Any  variations  in  man¬ 
hours  between  projects  of  the  same  size  are  due  in  part  to  the  differences 
in  the  situation  under  which  the  effort  is  accomplished  (its  production 
characteristics).  A  better  tool  reduces  these  variations  by  adjusting  for  the 
production  characteristics.  If  possible,  the  tool  should  divide  the  variation 
sources  into  mutually  exclusive  categories.  Otherwise,  if  covariance  exists 
between  variation  sources,  the  tool  must  perform  additional  calculations. 

The  number  of  potential  production  characteristics  is  enormous  so 
some  reasonable  limit  must  be  found.  What  is  the  minimum  set  of  data 
needed  to  build  a  model?  Given  the  definition  and  process  of  software 
support,  any  software  support  cost  estimation  tool  needs  to  account  for  at 
least  the  following  parameters: 

1)  the  magnitude  of  the  software  change  (size). 

2)  the  ease  of  altering  the  software  (maintainability). 

3)  the  organizational  efficiency  of  changing  software  (productivity). 

4)  the  time  allowed  for  the  change  (schedule). 

These  parameters  are  not  independent.  Some  dependencies  are 
intuitive.  For  example,  schedule  may  impact  size  (management  may 
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reduce  the  scope)  if  the  estimate  shows  the  work  can't  be  done  within  the 
schedule.  Productivity  should  increase  for  easily  maintainable  software. 

Other  interdependencies  emerged  from  the  literature  as  well. 

Furthermore,  the  first  three  parameters  can  be  divided  into  a  number  of 
factors  that  should  be  addressed  separately.  These  factors  as  well  as  the 
parameter  interdependencies  are  discussed  below. 

Size.  Since  size  is  the  primary  cost  driver  for  software  projects 
(Boehm;58),  size  is  often  the  starting  point  of  a  software  cost  model. 

Mukhopadhyay  and  his  associates  assert  that  "A  fundamental  problem  of 
software  estimation  is  the  determination  of  software  size" 

(Mukhopadhyay:  156).  While  Boehm  refers  to  "Annual  Change  Traffic"  as 
being  equivalent  to  development  product  size,  he  says  little  about  how  to 
derive  it  (Boehm:536).  For  software  support  changes,  the  change  needs  to 
be  expressed  in  some  term  of  size  that  accounts  for  the  number  of  lines  of 
software  to  be  changed.  Software  size  is  normally  expressed  as  Lines  Of 
Code  (LOC),  Source  Lines  Of  Code  (SLOC),  or  Deliverable  Source 
Instructions  (DSI).  All  three  units  basically  refer  to  a  single  line  of  code  as 
might  be  seen  on  a  code  printout. 

After  a  line  size  unit  is  identified,  a  choice  of  which  lines  to  count  or 
not  to  count  is  needed  to  further  define  size.  Low  and  Jeffery  list  five  ^ 

counting  variations:  1)  count  only  new  lines;  2)  count  new  lines  and  Y 

changed  lines;  3)  count  new  lines,  changed  lines,  and  reused  lines;  4)  count 
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all  delivered  lines  plus  temporary  scaffold  code;  and  5)  count  all  delivered 
lines,  temporary  code,  and  support  code'  (Low:64). 

Of  these  five  variations,  variation  2  is  preferred  since  it  best 
captures  only  what  was  changed  from  the  baseline  to  the  final  block 
change  product  with  the  exception  that  this  variation  does  not  account  for 
deleted  lines.  Variation  1  gives  a  count  of  zero  if  no  new  lines  were  added. 
Variation  3  captures  one  complexity  facet  but  counts  more  than  what  was 
changed.  Counting  reused  lines  can  capture  the  added  complexity  of 
designing  and  checking  for  potential  problems  in  a  large  program. 
However,  this  same  complexity  facet  can  be  captured  by  calibrating  the 
model  to  similar  sized  programs.  Variations  4  and  5  not  only  count  more 
than  what  was  changed,  but  they  also  require  extra  code  counts  to  capture 
the  size  of  temporary  development  code.  Temporary  development  code  is 
not  part  of  the  baseline  and  is  not  delivered.  Once  past  the  sizing  units 
and  line  selection,  an  estimate  of  the  size  of  the  change  is  still  needed. 

According  to  current  literature,  there  are  three  general  methods  of 
deriving  size  which  are  available  to  the  estimator.  The  first  method  is 
analogy  in  which  a  similar  effort  of  known  size  is  selected  and  its  size 
becomes  the  estimate  (Reifer:159).  The  second  method  is  expert  analysis 
where  an  expert  estimates  the  size  of  the  effort  based  on  previous 
experience  (Reifer:159,160).  The  third  method.  Function  Point  analysis,  is 

'  Support  code  used  in  this  context  is  code  which  supports  development  (such  as  stubs,  drivers,  or  tests)  and 
not  code  which  is  produced  during  the  support  phase. 
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a  process  that  uses  software  functions  to  predict  size  and  complexity 
(Reifer:159).  All  three  of  these  methods  typicaUy  have  been  applied  to 
estimating  development  software  size.  However,  software  support  sizing 
can  have  unique  differences  that  might  not  exist  during  development  size 
estimating. 

Once  a  software  product  enters  support,  three  changes  can  occur  to 
the  baseline  code.  Lines  of  code  can  be  added,  modified,  or  deleted.  Size 
measurements  historically  have  focused  on  the  original  development  size 
by  creating  new  code  where  none  previously  existed.  However,  software 
support  does  not  always  develop  completely  new  requirements  and  a  code 
sizing  technique  for  support  is  needed  for  code  modification  and  deletion 
activities.  Two  techniques  that  consider  size  for  changes  other  than  new 
code  were  found  in  the  literature. 

The  first  technique  addresses  code  modification  and  comes  from 
Boehm's  conversion  cost  estimating  relationship  (Boehm: 558).  For  this 
research,  converting  old  code  to  a  new  application  is  tantamount  to 
modifying  code  within  an  existing  application.  The  equivalent  delivered 
source  instructions  (EDSI)  for  a  number  of  adapted  DSI  (ADSZ)  is  found  by 
multiplying  the  latter  by  a  conversion  adjustment  factor  (CAP)  (see 
equation  2.1). 
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EDSI={ADSI)^^ 

100 


Eq.  2.1 


where  EDSI  =  equivalent  delivered  source  instructions 

ADSI  =  adapted  delivered  source  instructions 
CAF  =  conversion  adjustment  factor 

The  CAF  can  be  viewed  as  a  percentage  fraction  of  the  adapted  (modified) 
code  size  and  is  the  sum  of  two  parts,  the  adaptation  adjustment  factor 
(AAF)  and  the  conversion  planning  increment  (CPI).  The  AAF  is  found  by 
calculating  a  weighted  average  of  the  percentages  of  design  modified  (DM), 
code  modified  (CM),  and  integration  required  for  modified  software  (IM) 
(see  equation  2.2). 

/1/1F=0.4(KDAI)+0.3(XCM)+0.3(K/Af)  2.2 

where  AAF  =  adaptation  adjustment  factor 
DM  =  %  design  modified 
CM  =  %  code  modified 
IM  =  %  integration  for  modified  software 

Boehm  selected  weightings  based  upon  a  general  average  fraction  of  effort 

devoted  to  design,  code,  and  integration/test  (Boehm:  137).  The  CPI  value 

is  found  by  using  a  simple  table  developed  by  Boehm.  The  table  is  shown 

in  Table  2.1. 
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Table  2.1 


CPI  Valuos  (Boehm;558) 


CPI 

Value 

Level  of  Conversion  Analysis  and  Planning 

0 

None 

1 

Simple  conversion  schedule,  acceptance  plan 

2 

Detailed  conversion  schedule,  test  and  acceptance  plans 

3 

Add  basic  analysis  of  existing  inventory  of  code  and  data 

4 

Add  detailed  inventory,  basic  documentation  of  existing  system 

5 

Add  detailed  inventory,  detailed  documentation  of  existing  system 

As  mentioned  earlier,  CAF  =  AAF  +  CPI.  Using  this  relationship  and 
substituting  equation  2.2  for  AAF,  a  more  detailed  form  of  the  ED  SI 
equation  is  derived  (equation  2.3)  as  shown  below. 

EDSI-(ADSD  30*CAf^-0.30*/Af)  +CPI  Eq  2  3 

where  EDSI  =  equivalent  delivered  source  instructions 

ADSI  =  adapted  delivered  source  instructions 
DM  =  %  design  modified 
CM  =  %  code  modified 
IM  =  %  integration  for  modified  software 
CPI  =  conversion  planning  increment 

Once  computed,  an  EDSI  can  be  substituted  in  cost  model  equations  in 

place  of  a  pure  development  DSI  measure. 

The  second  technique  that  sizes  code  other  than  new  code  comes 

from  Reifer  Consultants  in  their  manual  for  SoftCost-R  (Kane:R-83).  This 

sizing  model  differentiates  among  five  categories  for  a  support  line  of  code. 
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A  line  can  be  new,  added,  deleted,  modified,  or  retested.  The  model  also 
distinguishes  between  actions  that  occur  upon  a  single  LOG  and  those 
within  a  module  of  code.  Besides  differentiating  between  lines  and 
modules,  there  are  two  subtle  differences  between  Low  and  Jeffery's 
change  categories  (page  2.9)  and  those  proposed  by  SoftCost-R.  The  first  is 
a  category  to  count  code  that  is  not  changed  but  is  retested  during  the 
block  change  process.  The  second  difference  is  a  splitting  of  the  added 
category  based  on  the  source  of  the  added  line.  The  SoftCost-R  new 
category  represents  a  line  created  from  scratch  for  the  block  change  while 
the  added  category  represents  a  line  created  for  some  other  program  that 
is  added  (reused)  as  part  of  the  block  change.  The  equivalent  size  is  the 
sum  of  the  size  of  new  code  plus  the  size  of  reused  code  (see  equation  2.4). 

Equivalentsi^=NeWsi„^^Reuseds^  Eq.  2.4 

Each  size  category  is  weighted  as  shown  in  Table  2.2. 

Table  2.2 

Reused  Code  Weightings  (Kane:R-83) 


Percent  Weight 

Type  of  Reused  Code 

27 

Modified  Modules 

15 

Deleted  Lines 

53 

Added  Lines 

24 

Changed  Lines 

11 

Deleted  Modules 

17 

Retested  Modules 
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Reifer  includes  a  set  of  assumptions  for  e^  .h  of  the  five  categories  to  allow 
estimators  to  properly  categorize  changed  lines  (Kane:R-84).  The 
assumptions  are  listed  below: 

•  New  code  will  be  developed  according  to  a  well-defined  process  and  set 
of  product  standards,  including  those  for  documentation. 

•  Reused  code  may  not  necessarily  have  been  developed  according  to  the 
well-defined  process  and  products  standards.  Its  documentation  may  or 
may  not  be  up-to-date. 

•  Reused  code  will  be  identified  during  the  preliminary  design  phase  so 
that  code  added,  deleted,  and/or  changed  within  units  will  go  through 
all  subsequent  life  cycle  activities. 

•  Deleted  lines  require  reduced  design,  coding,  and  documentation  effort, 
and  no  testing  of  the  deleted  lines. 

•  Changed  code  will  take  the  same  implementation  effort  (i.e.,  detailed 
design,  coding,  and  unit  testing)  as  new  code  in  proportion,  but  with 
less  documentation  and  testing. 

•  Reused  code  will  not  include  code  added,  deleted,  or  modified  in  any 
other  way. 

•  Retested,  unmodified  code  will  require  revalidation  of  the  interface 
design  and  retesting  activities  only. 

•  All  modified  and  reused  code  will  be  completely  retested  and  requalified 
prior  to  integration  into  the  system. 

The  total  of  the  reused  code  is  the  weighted  sum  of  all  the 
appropriate  code  types  as  shown  in  Table  2.2.  The  following  equation  is 
the  complete  expansion  of  equation  2.4  according  to  Table  2.2. 

^^Equivakm  Ones  *  ^ 

K.5U(Ui€djjJ^+{.2AChmgedu^)  Eq.  2.5 
+(.l  IDekted^^) 

Each  part  of  the  equation  should  be  expressed  in  the  same  units. 

Generally  this  will  be  LOG,  although  it  could  be  a  percentage  of  the  total 
code.  Equation  2.5  shows  that  added  LOCs  are  weighted  less  than  new 
LOCs.  In  addition,  since  the  weightings  total  more  than  1.0,  this  equation 
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allows  a  highly  modified  portion  of  code  to  cost  more  than  functionally 
equivalent  code  developed  from  scratch. 

This  literature  review  on  size  has  shown  that  any  size  estimate 
involves  selecting  units,  an  appropriate  set  of  LOCs,  and  an  overall  sizing 
methodology.  For  a  support  size  estimate,  Boehm's  conversion  relationship 
and  Reifer's  sizing  model  were  presented  as  tools  that  can  account  for  size 
other  than  new  code.  The  major  point  to  be  made  about  size  estimation  is 
that  better  size  estimates  produce  better  cost  estimates.  Reifer  states 
"Because  most  of  the  popular  software  cost  estimating  models  in  use  today 
are  extremely  sensitive  to  size  inputs,  there  is  a  direct  correlation  between 
improving  the  capability  to  predict  both  size  and  cost"  (Reifer:  159). 
Therefore,  size  estimation  should  provide  the  foundation  of  the  estimate 
and  the  remaining  parameters  of  maintainability,  productivity,  and 
schedule  should  be  used  to  fine  tune  the  estimate.  The  next  subsections 
address  these  remaining  three  parameters. 

Maintainability.  Maintainability  is  a  design  feature  of  the  software, 
its  documentation,  and  its  environment.  The  design  sets  the  structure  of 
the  code  under  which  support  programmers  can  alter  and  maintain  the 
code.  The  documentation  communicates  this  structure  and  the  software 
environment  bounds  the  programmer’s  fireedom  to  alter  the  code. 

Therefore,  these  three  characteristics  affect  maintainability  and  help 
determine  if  the  software  itself  has  been  designed  to  allow  easy 
modification  or  if  the  software  documentation  understandable  and  current. 
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It  is  easy  to  underestimate  the  efifect  of  documentation  on  support  effort, 

but  according  to  Robson  and  his  coauthors,  "50-90%  of  maintenance  time  is 

devoted  to  program  comprehension"  (Robson;79).  The  authors  go  on  to 

state  that  comprehension  can  be  affected  by  the  design  of  the  software,  the 

style  in  which  the  software  was  written,  the  convention  followed  when 

naming  ariables  in  the  software,  the  presence  of  indentation  and  the 

number  of  spaces  used  in  the  format  of  the  software,  and  the  presence  of 

comments  to  explain  the  software  (Robson:80,81). 

Robson  and  his  coauthors  also  discuss  automated  systems  that  have 

been  developed  to  help  the  maintainer  better  understand  the  software  but 

drew  no  conclusions  on  the  usefulness  of  those  systems  (Robson:80-83). 

However,  there  is  an  interdependency  between  the  maintainability 

parameter  and  the  productivity  parameter.  Does  the  maintenance 

organization  have  and  use  such  automated  systems?  If  so,  what  is  the 

effect  on  productivity?  Answers  to  these  questions  need  to  be  obtained  to 

properly  tune  the  effort  predicted  from  size  alone.  The  discussion  so  far 

has  dealt  with  the  software  itself  and  has  excluded  the  documentation  of 

the  software.  The  documentation  presents  other  potential  pitfalls  which 

are  discussed  in  the  following  paragraphs. 

Documentation  must  not  only  be  understandable  it  must  be  precise 

enough  to  prevent  misunderstanding.  Cioch  states 

In  practice,  when  one  wishes  to  ascertain  the  understandability  of  a 
particular  software-related  product,  one  is  often  concerned  not  only 
with  the  degree  to  which,  or  the  ease  with  which,  the  information  is 
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grasped  mentally,  but  also  the  degree  to  which  it  is  misinterpreted 
by  the  person  examining  the  product.  (Cioch:85) 

He  suggests  that  misinterpretations  are  more  dangerous  than  lack  of 

comprehension.  Misinterpretation  is  harder  to  detect  and  can  cause 

unintentional  changes  to  the  specification  which  result  in  software  that 

doesn't  match  what  the  user  expects.  When  misinterpretation  mistakes  go 

unnoticed  in  the  current  change,  they  must  be  fixed  later  (Cioch:86). 

Another  possible  constraint  on  maintainability  is  the  hardware 

environment  where  the  software  resides.  In  real-time  environments  such 

as  avionics,  software  is  especially  susceptible  to  memory  and  throughput 

constraints  imposed  by  hardware.  As  the  operating  memory  available 

decreases,  programs  have  less  room  to  expand  for  corrections  or 

enhancements.  This  lack  of  room  forces  support  programmers  to  write 

more  size-efficient  code  and  increases  the  effort  needed  to  write  the  code. 

Throughput  responds  similarly.  As  the  available  throughput  of  software 

decreases,  programs  have  less  time  to  manipulate  data  and  communicate 

with  other  programs.  This  restricted  ability  also  forces  support 

programmers  to  write  more  efficient  real-time  code  in  terms  of  throughput 

(or  timing).  Again  the  effort  required  increases.  In  a  continuation  of  the 

Hughes  study  of  the  Predictive  Software  Cost  Model,  SYSCON  quantified 

these  effects  for  several  different  support  phases  (see  Table  2.3).  In  Table 

2.3,  the  timing  fill  is  equivalent  to  throughput. 
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Table  2.3 


Constraints  of  Memory  and  Timing  (SYSCON:33) 


Support  Phase 

%  Memory  Fill 

%  Timing  Fill 

Requirements  Review 

1.42X“* 

1.33X”® 

Design 

2.00X’“ 

1.82X’“ 

Development 

1.88X’“ 

1.82X’®’ 

Integration 

1.S9X”® 

1.55X“® 

Test  &  Evaluation 

1.32X“" 

1.39X*“ 

Documentation 

1.13X“' 

1.09X’“ 

Reproduction/I  nstallation 

1.04X““ 

1.04X’®® 

For  both  restrictions,  the  equations  apply  only  if  the  percentage  is  greater 
than  or  equal  to  75%.  SYSCON  determined  that  lower  percentages  had  no 
effect  on  cost  (SYSCON:41). 

The  PRICE'S  model  describes  the  effects  of  available  speed  (time) 
and  memory  utilization  as  one  relationship  (see  Table  2.4).  This  model 
shows  that  the  speed  and  memory  constraints  have  a  much  greater  effect 
on  cost  than  on  schedule.  In  Table  2.4,  normalized  costs  greater  than  1.00 
represent  an  effort  increase  beyond  that  for  an  unconstrained  effort. 
Utilization  ratios  less  than  0.50  have  no  effect  on  cost. 
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Table  2.4 


Utilization  of  Available  Speed  and  Memoiy  (Boehm;5i6) 


Utilization 

Normalized  Cost 

Normalized  Schedule 

0.50 

1.00 

1.00 

0.60 

1.08 

1.00 

0.70 

1.21 

1.00 

0.80 

1.47 

1.05 

0.85 

1.73 

1.10 

0.90 

2.25 

1.18 

0.95 

3.78 

1.35 

Productivity.  Following  maintainability,  the  second  major 

parameter  needl’d  to  fine  tune  an  effort  estimate  is  productivity. 

Productivity  is  the  measure  of  an  organization's  efficiency  of  converting  a 

conceptual  change  into  reality.  The  less  time  and  resources  required,  the 

more  efficient  the  organization.  Normal  organizational  inefficiency  takes 

the  first  bite  out  of  productivity.  Fried  states 

People  in  fi)rmally  organized  groups  cannot  be  productive  100%  of 
the  time  for  extended  periods.  According  to  general  overhead 
estimates,  in  the  average  organization,  at  least  25%  of  employee 
time  is  required  for  vacations,  sick  leave,  personal  time  off,  training, 
coffee  breaks,  and  administrative  and  organizational  meetings.  In 
addition,  10%  of  employee  time  (a  conservative  estimate)  is 
nonproductive  because  of  late  completion  of  activities  on  which  the 
employee  depends,  poor  work  scheduling,  personal  conversation,  and 
other  forms  of  idle  time.  (Fried:28) 

There  are  a  number  of  conceptual  factors  that  affect  productivity  of 
an  organization  engaged  in  software  maintenance.  Obvious  factors  which 
affect  Air  Force  SSAs  include  the  experience  level  of  both  management  and 
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maintainers,  maturity  of  the  maintenance  process,  software  engineering 
practices  and  methods,  familiarity  with  the  software  being  modified,  and 
resources  available  (computer  time,  specialized  software  tools,  etc.). 

Banker,  Datar,  and  Kemerer  cite  over  100  variables  to  explain  productivity 
(Banker:!).  However,  their  productivity  model  uses  only  five  variables:  the 
ability  of  the  project  team  members,  the  level  of  previous  experience  with 
the  application,  the  use  of  structured  analysis  and  design  software 
methodology,  the  level  of  hardware  response  time,  and  the  operational 
quality  of  the  resulting  system  (Banker:6).  The  last  variable  is  not  used  to 
predict  productivity  but  rather  to  determine  the  quality  of  the  products 
produced.  The  obvious  factors  affecting  Air  Force  SSAs  listed  earlier  in 
this  paragraph  have  only  one  element  in  addition  to  Banker's  model.  This 
conceptual  agreement  is  very  good  considering  Banker's  model  is  a 
research  tool  used  to  measure  the  productivity  of  software  maintainers 
working  for  a  commercial  bank.  Even  though  the  applications  and 
language  used  for  business  are  not  what  would  be  used  in  Air  Force 
weapon  systems,  the  models  suggest  that  a  small  set  of  variables  might  be 
used  to  estimate  productivity. 

A  benefit  of  successive  block  changes  for  software  supporters  is  the 
built-in  educational  experience  that  occurs  through  those  successive  block 
changes.  SYS  CON  quantified  this  relationship  for  different  support 
phases  (see  Table  2.5)  and  reported  that  the  maximum  time  of  this  effect 
is  six  years  (SYSCON:44).  At  the  end  of  six  years,  the  supporters  should 
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have  learned  the  maximum  amount  from  the  original  code.  This 
relationship  assumes  that  the  software  supporters  are  not  the  same 
programmers  who  developed  the  software. 

Table  2.5 

Learning  Effect  by  Phase  (SYSCON:33) 


Support  Phase 

Years  of  Support 

Requirements  Review 

1.61X 

Design 

1.64X’^* 

Development 

1.65X 

Integration 

1.65X 

Test  &  Evaluation 

1.58X”“ 

Documentation 

1.43X^ 

Reproduction/I  nstallation 

1.19X 

Symons  confirms  this  initial  productivity  increase  in  his  description 
of  DuPont's  support  productivity  versus  system  age  (Symons:  149). 

DuPont's  productivity  improved  from  about  1.5  work-hours  per  function 
point  to  about  0.25  work-hours  per  function  point'  in  the  span  of  about  3 
years.  However,  after  those  initial  three  years,  the  productivity  slowly 
decreased  to  near  1.0  work-hour  per  function  point  during  the  next  15 
years.  As  plotted  in  Figure  2.1,  these  two  trends  exhibit  a  classic  "bath¬ 
tub"  shape,  an  initial  decrease  in  required  effort  (increase  in  productivity) 
followed  by  a  steady  effort  increase  (decreasing  productivity)  for  the 

'  A  function  point  is  another  sizing  method.  In  this  case,  one  function  point  can  be  considered  proportional 
to  one  line  of  code.  (See  Symons  for  more  information  on  function  points). 
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remaining  support  life  span  (Symons:  150).  Symons  attributes  the  slow 
rise  in  required  effort  to  technical  deterioration  because  the  original 
pristine  design  becomes  degraded  from  constant  maintenance  and 
enhancement  (Symons;  150). 


Figure  2.1  -  Support  Productivity  versus  System  Age  (Symons:  149) 


Lehner  also  describes  this  bath-tub  phenomenon  as  an  initial  3-year 
decrease  in  the  corrective  portion  of  maintenance  from  about  25%  to  15% 
followed  by  a  slower  but  steady  9-year  increase  up  to  45%  (Lehner:  135). 
Lehner  points  out  that  this  behavior  is  more  prevalent  within 
environments  where  the  requirements  are  constantly  changing,  and  less 
prevalent  where  the  requirements  are  static  (Lehner;  137). 

A  third  observer  of  design  deterioration  is  Yuen.  He  confirms 
decreasing  productivity  with  age  in  his  evolution  dynamics  report.  He 


states  that  "the  original  structure  of  a  piece  of  large  software  is  inevitably 
corrupted  each  time  the  software  is  modified"  (Yuen;  160). 

Schedule.  The  last  major  fine  tuning  parameter,  behind 
maintainability  and  productivity,  is  schedule.  This  variable  strongly 
interacts  with  productivity.  Fried  espouses  that  schedule  is  a  balance  of 
costs.  Shortening  or  lengthening  a  schedule  almost  always  increases  the 
cost.  Lengthening  a  schedule  also  delays  the  benefit  of  a  new  system 
(Fried;28).  Fried  argues  that  schedule  should  be  driven  by  team  size 
because  each  member  in  a  programming  group  must  spend  some  time 
communicating  and  interacting  with  others  in  the  group  (Fried:28).  Thus, 
an  excessively  large  group  requires  an  excessive  amount  of  communication. 
According  to  Fried,  the  formula  for  computing  the  number  of  possible 
interactions  (1)  between  a  group  of  K  people  is  given  in  equation  2.6. 
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Eq.  2.6 


where  I  =  number  of  possible  interactions 
K  =  number  of  people  in  a  group 

Fried  then  uses  the  equation  in  an  example  of  90  people  working  a 
standard  40  hour  work  week.  Out  of  3,600  available  hours,  only  538  are 
productive.  This  is  independent  of  how  the  90  people  are  organized 
(Fried:28-29).  Groups  of  10  people  or  less  are  the  most  productive  while 
larger  groups  spend  more  time  communicating  for  each  additional  team 
member  (Fried:29).  Fried  suggests  that  using  proper  tools  and  modern 
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programming  techniques  reduces  the  number  and  length  of 
communications  (Fried:35). 

The  support  schedule,  whether  driven  by  team  size  or  management 
dictate,  combines  with  productivity,  maintainability,  and  size  as  minimum 
parameters  of  an  optimal  estimation  tool.  Of  these  four  parameters,  size 
is  the  most  important.  The  other  three  can  be  considered  to  fine  tune  an 
effort  prediction  based  solely  on  size.  How  a  specific  model  accounts  for 
these  parameters  determines  the  unique  characteristics  of  that  model. 

The  next  section  briefly  examines  how  the  Air  Force  recommended  models 
handle  these  parameters. 

Current  Suiqxxt  Model  Paradigms 

As  stated  earlier,  there  are  four  models  recommended  by  the  Air 
Force  Cost  Analysis  Agency.  They  are  1)  Revised  Intermediate 
Constructive  Cost  Model  (REVIC),  2)  the  System  Evaluation  and 
Estimation  of  Resources  (SEER),  3)  the  Software  Architecture  Sizing  and 
Estimating  Tool  (SASET),  and  4)  PRICE-SL.  The  REVIC,  SASET,  and 
SEER  models  represent  software  support  size  as  a  constant  number  of 
LOC  changes  made  to  the  software  per  year  (Silver2:3-12:  REVIC;  1.4; 
SEER:6-5).  The  term  used  in  this  research  for  support  size,  Annual 
Change  Traffic  (ACT),  is  borrowed  fi:om  COCOMO.  The  ACT  concept  is 
simple  in  that  the  estimator  determines  what  percentage  of  total  SLOC 
will  be  changed  per  year  and  provides  this  to  the  model.  ACT  models  a 
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system  under  continuous  change.  The  best  interpretation  for  a  system 
employing  the  block  change  process  for  support  is  a  continuous  series  of 
block  changes  with  each  effort  being  identical  in  size  and  taking  exactly 
one  year  to  complete.  None  of  the  models  is  flexible  enough  to  handle 
variation  from  the  one  year  schedule. 

As  for  the  maintainability  parameter,  only  SEER  accounts  for 
decreasing  maintainability  from  memory  and  throughput.  For 
productivity,  none  of  the  models  seem  to  account  for  learning  curve  effects 
or  for  design  entropy  effects,  nor  do  they  capture  the  "bath-tub"  curve 
supported  by  the  literature.  Flexibility  to  handle  various  schedules, 
changes  in  memory  and  throughput,  a  learning  curve,  and  design  entropy 
is  necessary  to  model  the  real  world.  REVIC/COCOMO  algorithms  can  be 
adapted  to  accept  this  flexibility. 

COCOMO  Model  Description 

Of  the  four  Air  Force  recommended  models,  both  SEER  and 
PRICE-SL  are  proprietary  models  and  are  not  subject  to  unconstrained 
alteration.  Of  the  remaining  two,  SASET  and  REVIC,  REVIC  is  much 
easier  to  calibrate  (Ourada:4.8).  Since  a  model  which  could  be  freely 
altered  and  easily  calibrated  was  needed  to  test  our  h)^otheses,  model 
research  was  oriented  towards  understanding  the  algorithms  and 
construction  of  REVIC.  REVIC  is  essentially  an  implementation  of 
Boehm's  COCOMO  with  a  few  additions.  Therefore,  a  discussion  of 
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COCOMO  is  warranted  since  it  directly  contributes  to  an  understanding  of 
REVIC.  The  COCOMO  model,  as  published  in  Barry  Boehm's  Software 
Engineering  Economics,  has  three  levels  of  detail:  the  basic,  intermediate, 
and  detailed  levels.  Each  of  these  COCOMO  levels  are  described  in  the 
following  sections. 

Basic  Description.  The  basic  COCOMO  model  predicts  development 
man-months  from  one  input.  That  input  is  size  measured  in  thousands  of 
delivered  source  instructions  (KDSI)  (Boehm:57).  The  equation  for  the 
basic  model  is  shown  in  equation  2.7. 

MM=a{KDSrf*  ^^2.7 

where  MM  =  Man-Months 

o  =  coefficient  factor 
6  =  exponent  factor 

This  equation  reflects  the  exponential  characteristic  of  large  systems.  If  a 
software  system  doubles  in  size,  the  effort  needed  to  produce  that  system 
more  than  doubles.  This  non-linear  effect  helps  estimators  predict  a 
variation  in  man-months  given  a  variation  in  KDSI. 

Since  equation  2.7  is  the  basic  COCOMO  equation,  it  should  only  be 
used  for  first-cut  approximations  (Boehm:  114).  Although  this  equation  can 
account  for  large-scale  variations  in  the  characteristics  of  any  project,  the 
parameter  pair  a  and  b  can  be  changed  to  accommodate  three  basic  modes 
of  a  project  environment:  the  organic,  semidetached,  and  embedded  modes 
(Boehm:78-79).  These  basic  modes  are  summarized  in  Table  2.6. 
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Table  2.6 


Project  Modes  for  the  Basic  COCOMO  Model  (Boehm;75-85) 


Mode 

Description 

Equation 

Organic 

-  Thorough  understanding  of  project 

-  Highly  experienced  personnel 

-  Stable  and  familiar  anvironment 

-  Minimal  need  for  innovation 

-  Low  premium  on  early  completion 

-  Relatively  small  size  (less  than  50  KDSI) 

MAf=2.4(JCD57)‘“ 

Eq.2.8 

Semidetached 

-  Considerable  understanding  of  project 

-  Intermediate  or  mixed  personnel 
experience 

-  Partial  experience  with  project  aspects 

-  Larger  sizes  (less  than  300  KDSI) 

-  Mixture  of  Organic  and  Semidetached 

MM=3.Q(KDSI)^^^ 

Eq.  2.9 

Embedded 

•  General  understanding  of  project 

-  Tight  constraints 

-  Complex  hardware  &  software 

-  All  sizes 

•  Take  up  hardware  slack 

AfM*3.6(A2)S7)‘^ 

Eq.  2.10 

Intermediate  Descripticn.  For  second-cut  approximations,  the 
intermediate  COCOMO  equation  (see  equation  2.11)  contains  15  more 
inputs  to  increase  the  accuracy  of  the  effort  estimate  (Gulezian:237). 

MMMKDSrf*  Eq.  2.11 

where  MM  =  man-months 
a  =  coefficient 

KDSI  =  thousands  of  delivered  source  instructions 
b  =  exponent 
n  =  product  function 

Cij  =  adjustment,  i  =  attribute  &  j  =  selection 
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The  Cij  adjustment  factors*  increase  the  usefulness  of  the  basic  model  by 
allowing  for  variations  in  15  project  attributes.  Each  factor  allows 
estimators  to  account  for  different  project  attribute  characteristics  and 
thus  fine  tune  the  estimate.  Estimators  choose  a  value  for  each  factor 
from  a  set  of  possible  values  ranging  from  slightly  below  one  to  slightly 
above  one  and  then  multiply  the  value  by  the  values  for  the  other  14 
adjustment  factors  to  produce  a  single  Effort  Adjustment  Factor  (EAF). 

The  15  factors  are  briefly  described  in  Table  2.7.  Estimators  choose  which 
value  to  multiply  into  the  EAF  based  upon  their  assessment  of  the 
attribute's  effect  on  the  project.  Estimators  choose  a  value  for  each  factor 
below,  near,  or  above  1.0  depending  on  whether  that  particular  attribute 
reduces,  preserves,  or  inflates  the  basic  effort. 


*  Adjustment  factors  are  also  known  as  cost  driver  attributes  (Boehm:  1 1 5),  effort  multipliers,  effort  adjustment 
factors,  and  cost  driver  multipliers  (Gulezian:237).  They  all  have  a  common  theme  -•  inputs. 
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Table  2.7 


Adjustment  Attributes  for 
Intermediate  COCOMO  Model  (Boehm:  118) 


Area 

Factor 

Description 

Multiplication 

Range 

Product 

RELY 

Required  Software  Reliability 

0.75-1.40 

DATA 

Data  Base  Size 

0.94-1.16 

CPLX 

Product  Complexity 

0.70-1.65 

Computer 

TIME 

Execution  Time  Constraint 

1.00-1.66 

STOR 

Main  Storage  Constraint 

1.00  -  1.56 

VI RT 

Virtual  Machine  Volatility 

0.87  -  1.30 

TURN 

Computer  Turnaround  Time 

0.87-1.15 

Personnel 

ACAP 

Analyst  Capability 

1.46  -  0.71 

AEXP 

Applications  Experience 

1.46  -  0.71 

PCAP 

Programmer  Capability 

1.42-0.70 

VEXP 

Virtual  Machine  Experience 

1.21  -0.90 

LEXP 

Programming  Language  Experience 

1.14-0.95 

Project 

MODP 

Modern  Programming  Practices 

1.24  -  0.82 

TOOL 

Use  of  Software  Tools 

1.24  -  0.83 

SCED’ 

Required  Development  Schedule 

1.23  -  1.00  -  1.10 

Table  2.8  shows  an  example  of  the  possible  values  for  the 
programmer  capability  (PCAP)  attribute.  As  the  programmer  rating  falls 
below  nominal,  the  effort  multiplier  increases.  The  opposite  case  is  also 
true.  For  cases  which  fall  between  two  definitions,  estimators  can 


SCED  has  two  multiplication  ranges.  A  factor  of  1 .0  represents  projects  with  a  nominal  schedule.  Reducing 
the  schedule  from  nominal  results  in  a  multiplication  range  of  1 .00  ■  1 .23.  Lengthening  the  schedule  from  nominal 
results  in  a  multiplication  range  of  1.00  -  1. 10.  In  both  cases,  successively  larger  multipliers  are  used  as  the 
schedule  departs  from  the  nominal  estimate. 
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interpolate  to  find  the  appropriate  multiplier.  Thus,  a  45th  percentile 
programmer  could  have  a  1.08  multiplier. 

Table  2.8 

Programmer  Ratings  and  Effort  Multipliere 


PCAP 

Rating 

Definition 

(Not  based  upon  experience,  only  capability) 

Multiplier 

Very  Low 

Ranked  at  the  15th  percentile  of  all  programmers 

1.42 

Low 

Ranked  at  the  35th  percentile  of  all  programmers 

1.17 

Nominal 

Ranked  at  the  55th  percentile  of  all  programmers 

mm 

High 

Ranked  at  the  75th  percentile  of  all  programmers 

0.86 

Very  High 

Ranked  at  the  90th  percentile  of  all  programmers 

0.70 

Detailed  Description.  Third  cut  approximations  require  the  most 
comprehensive  form  of  COCOMO,  the  detailed  COCOMO  model.  The 
detailed  model  increases  estimation  precision  by  breaking  out  all  15 
adjustment  factors  into  four  phases  of  development:  product  design, 
detailed  design,  code/unit  test,  and  integration/test  (Boehm: 364).  Although 
the  application  of  adjustment  factors  to  separate  phases  leads  to  a  more 
accurate  description  of  an  actual  development  process,  it  increases  the 
predictive  accuracy  by  only  2%  (Boehm:521).  This  small  increase  in 
estimation  accuracy  is  usually  not  worth  the  added  expense  of  assigning 
adjustment  factors  to  each  phase.  Thus,  the  detailed  level  of  the 
COCOMO  model  is  not  used  in  general  practice  and  most  estimators  use 
the  intermediate  form  (Gulezian:237). 
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CXXX)MO  Support.  The  COCOMO  model  normally  is  used  to 
estimate  the  development  effort  of  a  software  project  (REVIC:4).  But 
almost  all  the  attribute  factors  which  affect  the  development  process  also 
affect  the  support  process.  The  model  needs  only  a  few  adjustments  to 
switch  from  predicting  development  effort  to  predicting  support  effort.  The 
main  adjustment  required  is  scaling  the  man-months  of  effort.  A 
prediction  for  development  forecasts  the  entire  effort  for  the  development 
phase.  However,  support  effort  is  usually  for  a  fixed  period  of  time, 
t5q)ically  near  one  year.  In  a  sense,  the  support  model  scales  a  total 
development  effort  since  scaling  is  done  proportionally.  Boehm  calls  this 
scaling,  which  is  the  expected  percentage  of  code  changed  for  a  specific 
period  of  time  during  support,  the  Annual  Change  Traffic  (ACT) 
(Boehm:536).  For  example,  if  a  development  effort  prediction  was  120 
man-months  and  the  CT  was  10%,  the  expected  support  effort  for  one 
year  would  be  12  man-months. 

Another  support  adjustment  to  the  COCOMO  model  involves 
altering  three  of  the  adjustment  factors  shown  in  Table  2.7:  SCED,  RELY, 
and  MODP.  The  required  development  schedule  (SCED)  is  only  a  factor 
during  development  and  is  dropped  as  an  input  for  support  estimation 
(Boehm:  129).  The  next  adjustment  factor,  required  software  reliability 
(RELY),  measures  the  probability  that  the  software  will  perform  its 
intended  functions  satisfactorily  over  its  next  run  or  its  next  quantum  of 
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execution  time  (Boehm;372).  Table  2.9  shows  how  the  RELY  values 
change  from  development  to  support. 

Table  2.9 

RELY  Ratings  (6oehm:374,538) 


Phase 

Ratings  | 

Very  Low 

Low 

Nominal 

High 

Very  High 

Development 

0.75 

0.88 

1.00 

1.15 

1.40 

Support 

1.35 

1.15 

rnmm 

0.98 

1.10 

Table  2.9  quantifies  the  fact  that  programming  low  reliability  software 
during  development  requires  less  effort,  but  supporting  low  reliability 
software  requires  more  effort.  The  final  altered  adjustment  factor,  modern 
programming  practices  (MODP),  also  manifests  different  effects  between 
development  and  support  except,  in  this  case,  modern  programming 
practices  help  reduce  effort  in  both  development  and  support.  The 
difference  is  in  the  degree  of  effect  as  shown  in  Table  2.10. 
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Table  2.10 


MODP  Ratings  (6oehm:538) 


Phase 

Ratings  { 

Very  Low 

Low 

Nominal 

High 

Very  High 

Development 

1.24 

1.10 

1.00 

0.91 

0.82 

Support 

(Size) 

2K 

1.25 

1.12 

1.00 

0.90 

0.81 

8K 

1.30 

1.14 

1.00 

mm 

0.77 

32K 

1.35 

1.16 

1.00 

0.86 

0.74 

128K 

1.40 

1.18 

mm 

0.85 

0.72 

51 2K 

1.45 

1.20 

1.00 

0.84 

0.70 

For  small  sized  changes,  the  support  MODP  ratings  are  very  close  to 
development  MODP  ratings.  However,  as  the  change  size  increases,  the 
impact  of  MODP  increases  in  both  a  positive  and  negative  manner.  Thus, 
as  the  size  of  the  support  change  increases,  the  risk  and  payoff  of  using 
MODP  increases. 

The  previous  COCOMO  descriptions  show  that  COCOMO  has  three 
modes  and  levels  of  detail.  Those  simple  options  along  with  the  minor 
alterations  for  the  support  phase  make  COCOMO  a  relatively  simple  and 
usable  model.  While  REVIC  uses  all  three  modes,  the  intermediate  level 
of  detail,  and  the  support  alterations,  COCOMO  has  yet  another 
characteristic  that  makes  it  usable;  COCOMO  is  straightforward  to 
calibrate. 

Calilvation.  Calibration  of  any  model  can  improve  the  accuracy  of 
its  prediction.  In  fact,  Thibodeau,  in  his  evaluation  of  software  cost 
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estimating  models  for  the  Rome  Air  Development  Center,  showed  that  the 
calibration  of  model  parameters  may  be  as  important  as  the  structure  of 
the  model  in  explaining  estimating  accuracy  (Thibodeau:6-6).  If  the 
prerequisite  data  is  available,  all  three  levels  of  the  COCOMO  model  are 
straightforward  to  calibrate.  The  intermediate  COCOMO  model  can  be 
calibrated  in  three  ways  depending  upon  the  depth  of  calibration.  All 
three  calibrations  adjust  some  parameter(s)  of  the  COCOMO  model 
through  least  squares  regression  to  adjust  for  new  or  altered  historical 
data.  The  result  should  be  an  improved  model  which  predicts  better  for 
those  efforts  closely  resembling  the  historical  data  used  for  calibration. 
The  first  calibration  method  calibrates  only  the  coefficient  of  the  basic 
model  (see  equations  2,7  -  2.10).  Boehm  recommends  this  method  if  the 
project's  historical  data  has  less  than  ten  data  points  (Boehm:529). 
Calibrating  the  exponent  of  COCOMO  equations  with  less  than  ten  data 
points  may  unduly  bias  the  exponent  because  one  erroneous  data  point 
may  overwhelm  the  contribution  of  the  other  nine  data  points.  The  least 
squares  regression  equations  for  both  coefficient  and/or  exponent 
calibration  are  shown  in  equations  2.12  through  2.15. 
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Eq.  2.12 


L  MM 

i=l _ 

n 

£<?? 


Eq.  2.13 


where  i  =  1,  2,  ...  the  number  of  historical  data  points 

n  =  product  of  Cjj  adjustment  factors  for  a  data  point 
a  =  coefficient  for  a  set  of  data 
h  -  exponent  for  a  set  of  data  (given) 

=  temporary  variable  firom  equation  2.12 
MM^  =  man-month 

If  more  than  ten  historical  data  points  are  available,  then  the 
coefficient  and  the  exponent  can  be  calibrated  at  the  same  time.  The 
resulting  calibration  equations  are  still  least  squares  regressions  but 
include  the  log  function  to  account  for  the  exponent  and  are  solved 
simultaneously. 


where 


ao=n 

n 

a,=  LlogiKDSI,) 
i=l 

02=  E  Pog(«)S/,)]2 

i=i  tq  2. 

n 

d;,=  Elog(AfAf/ID, 
i=l 
n 

d,  =  E  log(3fAf/II),  log(«>57), 

/=1 

Ofl*  Og,  do,  d,  =  intermediate  variables  for  Eq.  2.15 
n  =  number  of  historical  data  points 
i  =  1,  2,  ...  the  number  of  historical  data  points 
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Eq.  2.15 


log(a)= 


2 


where  Go,  a^,  Gg,  do,  d,  =  intermediate  variables  from  Eq.  2.14 
a  =  coefficient  for  a  set  of  data 
b  =  exponent  for  a  set  of  data 

The  third  calibration  method  adjusts  the  coefficient,  exponent,  and 
all  the  effort  multipliers  for  each  effort  adjustment  factor  and  each  mode. 
In  this  calibration  method,  Gulezian  extends  the  least  squares  regression 
procedure  to  the  multivariable  case  and  improves  the  estimating  accuracy 
of  COCOMO.  For  Boehm's  original  database  (Boehm:496),  the 
intermediate  form  of  COCOMO  predicts  within  20%  of  the  actual  effort 
68%  of  the  time  while  Gulezian  has  improved  the  intermediate  model  to 
predict  within  20%  of  the  actual  effort  75%  of  the  time  (Gulezian:240). 

The  extra  accuracy  does  require  more  mathematical  manipulations  during 
calibration  and  would  likely  involve  using  a  personal  computer,  but  the 
extra  accuracy  is  available. 

COCOMO  Strengths.  The  choice  of  modes,  levels  of  detail,  and 
methods  of  calibration  point  to  one  of  the  advantages  that  COCOMO  has 
over  other  models:  COC  -0  is  flexible.  Estimators  have  had  access  to 
the  model  and  have  studied  the  model  for  over  ten  years  (Gulezian:236). 
This  open  model  permits  estimators  to  explore  inner  workings,  avoid 
pitfalls,  and  adapt  the  model  to  different  situations.  The  key  element  of 
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model  flexibility  is  the  ability  to  change  the  input  parameters  and 
environmental  factors.  The  parameters  and  factors  which  define  the  model 
are  not  magically  pulled  from  a  hat.  They  are  carefully  derived  through 
statistical  inference.  If  the  environment  of  the  software  project  changes 
severely,  then  estimators  can  rederive  the  parameters  and  adjustment 
factors  to  produce  a  model  which  more  accurately  reflects  the  current 
environment.  This  process  is  called  calibrating  the  model.  A  properly 
calibrated  model  has  been  shown  to  give  much  more  accurate  results  than 
an  uncalibrated  or  badly  calibrated  model  (REVIC;4). 

Another  advantage  of  COCOMO  is  its  wide-spread  use.  For 
example,  every  DOD  Defense  Plant  Representative  Office  (DPRO)  has  used 
the  COCOMO  model  to  help  estimate  software  (ENREV:1).  This 
commonality  helps  organizations  produce  results  which  are  understandable 
and  applicable  to  other  organizations.  Since  many  organizations 
understand  the  environmental  factors  that  affect  an  effort  estimate,  the 
organizations  can  speak  the  same  estimation  language. 

A  final  advantage  of  the  COCOMO  model  is  its  usability.  Dr.  Barry 
Boehm,  the  creator  of  the  COCOMO  model,  fully  explains  the 
implementation  of  the  model  is  his  book  Software  Engineering  Economics 
(Boehm;Chap  5  -  9,  23  -  30).  If  estimators  encounter  difficulties  when 
implementing  the  model,  they  can  refer  directly  to  the  expert’s  handbook. 
Furthermore,  since  the  model  is  simple  to  program  on  a  computer, 
software  versions  of  the  model  which  run  on  the  common  personal 
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computer  are  available.  The  Enhanced  REVIC  Advisor  (ENREV), 
developed  by  Ernst,  tutors  users  through  each  step  of  the  estimation 
process  and  explains  all  the  terms  needed  for  input  (ENREV;  12). 

CXXX)MO  Weaknesses.  Of  course,  the  COCOMO  model  is  not  the 
panacea  for  estimators'  problems.  The  model  does  have  weaknesses. 
Although  calibration  was  mentioned  as  a  strength,  it  is  also  a  weakness. 
While  calibration  offers  flexibility  to  change  environments,  it  is  mandatory 
when  environments  change  significantly.  The  model  becomes  inaccurate 
unless  it  is  calibrated  to  the  new  environment  (van  Genuchten:38)  and 
calibrating  the  model  is  not  trivial.  First,  input  data  concerning  the  two 
basic  equation  parameters  and  the  15  adjustment  factors  must  be 
available.  This  requires  enough  data  to  establish  trends  for  each  input  so 
that  new  values  can  be  inferred.  This  kind  of  data  is  scarce  and,  if  found, 
is  usually  of  poor  quality.  Secondly,  someone  with  statistical  skill  and 
COCOMO  knowledge  must  actually  perform  the  calibration.  Finding  a 
qualified  estimator  to  calibrate  a  model  can  be  difficult.  The  lack  of  these 
prerequisites  often  constrain  estimators  to  use  the  latest  model  on  hand 
regardless  of  the  model's  proper  calibration. 

Another  weakness  of  the  COCOMO  model  is  the  lack  of  specific 
adjustment  factors  for  the  support  phase  of  a  project.  Many  development 
attributes  do  indeed  set  support  attributes,  but  to  expect  that  support  is 
merely  an  extension  of  development  can  mislead  estimators  about  the  true 
nature  of  the  support  environment.  Some  support  factors,  such  as  support 
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growth  phases  or  block  changes,  are  unique  to  the  support  phase. 
COCOMO  does  not  sufficiently  provide  for  these  support-unique  inputs 
(Ferensl:8,9). 

The  greatest  weakness  of  the  COCOMO  model  is  the  model’s 
reliance  upon  KDSI  as  a  primary  input.  First  of  all,  KDSI  is  rarely 
estimable  early  in  a  software  life-cycle  (Bourque:  161).  But  fortunately,  as 
the  support  phase  nears,  actual  KDSI  values  can  be  input  into  a  support 
model.  Also,  the  definition  of  a  delivered  source  instruction  (DSI)  is  open 
to  some  interpretation.  Boehm  defines  a  DSI  as  a  single,  delivered  line  of 
code  which  excludes  comments  but  includes  job  control  language,  format 
statements,  and  data  declarations  (Boehm:59).  This  definition  reduces 
misinterpretation  but  does  not  eliminate  it.  Unless  estimators  follow  the 
explicit  definition  used  during  calibration,  they  will  bias  their  results. 
Finally,  one  DSI  for  a  particular  programming  language  is  not  necessarily 
equivalent  to  a  DSI  for  another  programming  language  (Lehner:  139).  As  a 
result,  simply  switching  programming  languages  can  bias  effort  prediction. 
These  three  weaknesses  of  mandatory  calibration,  missing  support 
adjustment  factors,  and  unreliable  KDSI  inputs  often  compel  estimators  to 
use  or  create  other  models. 

COCX)MO  &  REVIC.  As  mentioned  earlier,  REVIC  is  an 
implementation  of  the  COCOMO  model.  Maj.  Ray  Kile  programmed 
REVIC,  a  military  version  of  COCOMO,  using  a  data  base  of  28 1 
completed  contracts  from  the  Rome  Air  Development  Center  database 
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(ENREV;  1)  to  calibrate  a  new  set  of  coefficients  and  exponents  for  all  three 
modes  of  the  model.  REVIC  also  includes  an  additional  mode,  with  its 
own  coefficient  and  exponent,  for  Ada  developments  using  an  object- 
oriented  analysis  (REVIC: 2).  Also,  REVIC  also  has  4  extra  adjustment 
factors:  requirements  volatility,  required  reusability,  classified  security 
application,  and  management  reserve  for  risk.  To  further  aid  estimators, 
REVIC  includes  a  simple  sizing  model  which  sums  the  sizes  of  separate 
computer  software  components  (CSCs).  Users  can  provide  a  low,  high,  and 
most  probable  size  for  each  CSC.  These  CSC  size  ranges  can  help  set  a 
total  size  range.  The  extra  descriptors  combined  with  a  simple  interface 
have  made  REVIC  a  popular  model  throughout  DOD. 

Condusioa 

This  literature  review  examined  definitions  of  software  support  as 
well  as  the  processes  used  to  accomplish  support.  The  essential  areas  of  a 
capable  estimating  model  including  size,  maintainability,  productivity,  and 
schedule  were  explained.  Finally,  the  COCOMO  model  was  scrutinized  to 
provide  an  understanding  of  its  algorithms,  strengths,  and  weaknesses. 

The  sources  reviewed  all  indicate  that  the  existing  software  maintenance 
effort  estimation  tools  are  inadequate  for  estimating  software  support.  In 
general,  the  tools  are  inaccurate  or  inappropriate.  However,  many 
drawbacks  of  existing  models  have  been  addressed  in  the  literature  along 
with  possible  improvements.  Combining  some  of  the  improvements  and 
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addressing  some  of  the  drawbacks,  provides  a  potential  for  improving 
support  cost  models. 
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IIL  Methodology 

Chapter  Overview 

This  chapter  details  the  steps  needed  to  analyze  the  data  to  support 
each  of  the  hypotheses.  For  the  first  hypothesis,  the  functional  bottom-up 
construction  of  a  software  cost  estimation  model,  the  method  used  to  model 
the  various  levels  of  the  block  change  process  is  described.  Also  described 
is  the  process  used  to  develop  an  estimation  model  from  the  block  change 
process  model.  Since  no  data  was  available  to  validate  the  new  model,  a 
discussion  of  how  validation  can  be  accomplished  is  presented.  For  the 
second  h3rpothesis,  the  functional  top-down  calibration  of  a  statistically- 
based  software  effort  estimation  model,  discussion  is  limited  to  the  data 
collection  method  and  a  description  of  the  data  originally  sought.  Further 
work  on  this  hypothesis  was  impossible  due  to  lack  of  data.  However,  a 
method  for  formally  evaluating  model  performance  once  data  becomes 
available  is  presented.  This  discussion  follows  a  chronological  flow  of 
events  from  the  data  input  sequence  to  applying  statistical  rejection 
criteria. 

Hypothesis  1  Methodology 

Block  Change  Model  Methoddogy.  Documenting  the  block  change 
process  as  a  model  was  a  necessary  first  step  to  program  a  software 
support  cost  model.  The  objective  was  to  create  a  cost  model  that  is  closer 
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to  the  detailed  estimate  methodology  than  current  parametric  models.  The 
transition  from  paper  model  to  software  design  is  eased  by  the  proper 
selection  of  documentation  style.  This  research  uses  the  Object  Oriented 
Design  documentation  style  as  described  by  James  Rumbaugh  and  others 
in  Object-Oriented  Modeling  and  Design  because  of  its  versatility  and  prior 
experience  with  that  design  method.  Selecting  a  software  design 
methodology  to  document  the  real  block  change  process  has  two  main 
advantages.  The  first  is  the  reduction  in  software  system  design  time 
gained  by  avoiding  translation  of  requirements  firom  some  other 
abstraction  media  into  a  software  design.  The  second  is  direct  traceability 
from  the  model  to  the  software  design.  Both  of  these  advantages  resulted 
in  fewer  errors  in  the  final  product. 

Rumbaugh 's  design  method  revolves  around  three  model  types:  the 
object  model,  the  functional  model,  and  the  dynamic  model  (Rumbaugh:6). 
The  model  types  describe  different  characteristics  of  the  problem  space, 
and,  when  combined,  form  an  overall  description  of  a  system.  Each  model 
type  is  described  in  the  following  paragraphs. 

The  object  model  is  the  primary  description  of  the  agents  within  the 
process.  It  is  described  by  Rumbaugh  as  a  graphic  representation  that 
"captures  the  static  structure  of  the  system  by  showing  the  objects  in  the 
system,  the  relationships  between  objects,  and  the  attributes  and 
operations  that  characterize  each  class  of  objects"  (Rumbaugh:21).  iv  i 


object  is  defined  as  "a  concept,  abstraction  or  thing  with  crisp  boundaries 
and  meaning  for  the  problem  at  hand"  (Rumbaugh:21).  No  process  or 
temporal  information  on  the  system  is  captured  by  the  object  model. 

The  functional  model  shows  how  data  flows  from  one  process  to 
another  in  a  series  of  data  flow  diagrams  (Rumbaugh:123).  It  traces  the 
inputs  of  the  system  through  transformational  processes  within  the  system 
to  the  outputs  of  the  system.  No  information  on  the  static  structure  or  the 
temporal  behavior  of  the  system  is  captured  by  the  functional  model. 

The  dynamic  model  describes  the  temporal  behavior  of  the  system. 

It  uses  state  transition  diagrams  to  describe  "the  sequences  of  operations 
that  occur  in  response  to  external  stimuli"  (Rumbaugh:84).  No  structure 
or  process  information  is  captured  by  the  dynamic  model. 

The  importance  of  each  model  depends  entirely  on  the  system  being 
modeled.  For  example,  if  the  system  doesn't  change  over  time,  the 
dynamic  model  is  trivial  and  may  be  omitted.  The  purpose  of  each  model 
is  to  force  an  analyst  to  examine  and  understand  the  static  structural, 
procedural,  and  dynamic  facets  of  the  system.  Each  model  uses  a  standard 
set  of  labeled  symbols  to  pictorially  describe  system  behavior.  (A  summary 
of  each  model’s  notation  is  shown  in  Appendix  A.)  Label  definitions  for  all 
the  models  are  contained  in  a  data  dictionary.  The  data  dictionary  coupled 
with  the  graphic  nature  of  the  models  allows  the  analyst  to  interact  with 
system  experts  to  avoid  miscommunication. 
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Model  Des^a  Process. 

Step  1.  The  first  step  captured  the  attributes  of  a  single 
iteration  of  a  block  change  process  as  described  in  the  literature  review. 
The  description  was  in  the  form  of  an  object  model,  a  functional  model,  a 
dynamic  model,  and  a  data  dictionary.  The  object  and  functional  models 
provided  a  complete  picture  of  the  block  change  process,  so  the  dynamic 
model  was  dropped.  The  object  and  functional  models  were  verified  by 
consulting  with  HQ/AFMC  and  by  comparing  the  models  to  the  available 
literature. 

Step  2.  The  second  step  started  with  the  design  from  the 
models  of  a  single  block  change  process  and  evolved  into  the  models  of  a 
series  of  block  change  processes.  This  "ideal"  (described  in  Chapter  II) 
support  cost  estimation  model  for  the  block  change  process  was  also 
documented  in  the  form  of  an  object  model,  a  dynamic  model,  a  functional 
model  and  data  dictionary.  The  result  of  this  step  was  three  graphic 
representations  that  combine  to  form  a  description  of  a  software  support 
cost  estimation  model.  At  this  point  the  ideal  model  was  still  generic.  Any 
development  estimation  tool  could,  in  theory,  have  been  adapted  to 
emulate  the  ideal  model  by  repeated  development  estimates  or  by  recoding. 
The  ideal  model  was  verified  by  comparing  the  object,  functional,  and 
dynamic  models  with  the  Step  1  models  and  with  available  literature. 

Step  3.  The  third  step  instantiated  the  ideal  model  based  on 
the  COCOMO  equations  discussed  in  Chapter  II.  This  instantiation 
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placed  the  COCOMO  mathematical  models  into  the  ideal  model's  object, 
functional,  and  dynamic  representations.  Verification  consisted  of 
comparing  the  instantiation  with  the  ideal  model  and  ensuring  the 
COCOMO  mathematical  model  was  correctly  transcribed. 

Step  4.  The  fourth  step  was  to  prototype  the  instantiation. 
Visual  Basic  was  selected  as  the  coding  language  since  it  is  a  quick,  easy, 
object-centered  language  designed  to  create  code  for  the  Windows 
environment.  Rudimentary  verification  was  obtained  by  comparing  the 
estimate  of  a  single  block  change  of  all  new  code  to  a  REVIC  estimate  of  a 
development  effort  with  identical  parameters.  The  support  costs  were 
compared  with  other  models  to  determine  the  magnitude  difference 
between  Air  Force  recommended  models  and  the  new  model.  The  results 
are  presented  in  Chapter  IV. 

Completion  of  the  above  steps  did  not  result  in  a  calibrated  or 
validated  model,  only  a  feasible  model.  Calibration  and  validation 
required  actual  time  series  support  data  that  were  not  available.  The 
result  of  calibration  and  validation  would  have  been  an  expected  prediction 
accuracy.  Without  these  steps,  the  model  has  an  unknown  accuracy. 
However,  validation  can  be  accomplished  by  calibrating  the  model  and 
gathering  the  statistics  discussed  under  Model  Comparison  Methodology 
later  in  this  chapter. 
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Hypothesis  2  Methodology 

Data  Collection.  Data  could  not  be  obtained  to  examine  the  effect  of 
functional  calibration  on  model  accuracy.  (For  a  full  account  of  the 
problems  encountered,  please  refer  to  Chapter  IV.)  The  following 
paragraphs  discuss  what  type  of  data  needed  to  be  collected  and  why. 

Historical  data  from  the  software  block  change  process  was  needed 
from  as  many  combat  aircraft  as  possible.  As  a  minimum,  for  each  block 
change,  three  pieces  of  data  were  needed:  the  size  of  the  effort  (divided 
into  new,  modified,  and  deleted  lines)  measured  in  thousands  of  lines  of 
delivered  code  (KDSI)i  the  magnitude  of  the  effort  to  produce  the  code 
measured  in  man-months  (MM),  and  a  functional  description  to  place  the 
data  into  one  of  our  proposed  functional  categories. 

Also  needed  were  some  limited  data  concerning  the  detailed 
characteristics  of  each  block  change  to  help  fine  tune  a  model's  predictive 
capability.  The  data  collection  forms  prepared  to  obtain  this  data  are 
shown  in  Appendix  B.  However,  the  data  were  not  available.  Since  the 
research  assumes  that  KDSI  is  the  single  best  predictor  of  effort,  the 
inability  to  obtain  detailed  characteristics  (other  than  size)  should  not 
hinder  the  ability  to  determine  whether  functional  division  of  block 
changes  improves  predictive  accuracy.  Extra  block  change  characteristics 
could  help  determine  to  what  degree  functional  division  improves  accuracy 
for  each  particular  model.  Collection  of  extra  descriptive  data  suitable  for 
each  model  was  simply  impractical  due  to  time  and  money  constraints. 
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Therefore,  the  potential  benefit  of  setting  the  production  characteristic 
input  variables  was  balanced  against  the  potential  error  (and  effort 
required)  which  might  be  introduced  by  choosing  inappropriate  values,  and 
a  decision  was  made  to  use  the  nominal  values  provided  in  the  model  for 
those  inputs. 

Attempts  were  made  to  obtain  historical  block  change  data  from  two 
basic  sources.  The  first  source  was  existing  Air  Force  databases  which 
have  already  compiled  the  input  values  and  output  values  concerning  this 
research.  As  stated  in  Chapter  I,  many  prediction  models  are  built  by 
collection  and  statistical  regression  of  historical  data.  It  seemed  natural 
that  historical  data  would  be  systematically  collected  and  stored  to  help 
make  new  models  or  improve  existing  ones.  While  the  Air  Force 
recognizes  the  need  for  historical  data,  the  current  databases  were  found 
to  contain  data  for  software  development  but  not  software  support. 

Because  of  this  lack  of  support  data,  questionable  accuracies  (Ourada:4. 1), 
and  unusable  variable  formats  of  the  database,  no  useful  data  was 
obtained  from  this  source. 

It  was  expected  that  more  and  higher  quality  block  change  data 
could  be  obtained  by  contacting  the  System  Project  Offices  (SPOs)  located 
at  Wright-Patterson  AFB  (WPAFB).  Virtually  every  Air  Force  combat 
aircraft  is  represented  by  some  SPO  located  on  the  base.  The  SPOs 
assisted  in  the  collection  of  some  data  by  providing  contacts  within  the 
appropriate  software  maintenance  organization  (SMO).  In  all  cases,  the 


3.7 


SMO  was  at  an  Air  Logistic  Center  (ALC)  and  the  ALCs  provided  all  the 
data  found. 

Model  Conqiarison  Methodology 

This  section  describes  how  to  recalibrate  existing  (and  future) 
support  cost  models  and  gauge  the  resulting  accuracy  increase.  This 
methodology  is  generic  and  can  be  used  with  any  software  cost  model  once 
data  becomes  available.  The  data  requirements  are  discussed  under 
Hypothesis  2  Methodology.  Recall  from  Chapter  II  that  ten  data  points  or 
more  are  required  for  accurate  calibration  of  the  REVIC  exponent.  Ten  or 
more  data  points  should  suffice  as  a  minimum  for  other  models  as  well. 
Model  calibration  should  be  done  according  to  the  User's  Manual  for  the 
software.  Once  the  calibration  procedure  is  complete  the  model  is 
calibrated  to  the  new  data  set  and  will  be  ready  for  estimating. 

Data  Input  Sequence.  If  data  had  been  available,  the  models  would 
have  been  operated  under  three  different  scenarios.  The  first  scenario  was 
to  input  no  calibration  data  at  all.  In  other  words,  this  scenario  did  not 
include  recalibrating  the  model.  The  model  was  to  be  run  "out  of  the  box" 
using  its  existing  calibration.  The  predictions  obtained  from  this  scenario 
would  serve  as  the  baseline  to  determine  the  predictive  improvements  of 
each  subsequent  scenario.  The  second  scenario  included  recalibrating  the 
models  based  upon  all  the  block  change  data  from  all  the  functional 
categories.  Although  this  scenario  does  not  functionally  calibrate  the 
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models  according  to  categories  chosen  in  Chapter  I,  this  calibration  should 
produce  a  model  that  is  functionally  narrowed  to  the  area  of  OFP  software. 
The  models  calibrated  in  this  scenario  were  expected  to  predict  better  than 
the  uncalibrated  models  under  the  first  scenario.  The  third  scenario 
included  recalibrating  the  models  based  upon  the  inputs  firom  the 
functionally  stratified  data.  The  models  calibrated  according  to  the  third 
scenario  were  expected  to  predict  the  best. 

A{^y  Statistics.  Statistical  techniques  could  be  used  to  evaluate 
which  scenario  produces  the  best  predicting  model.  Devore  defines  a 
statistic  to  be  any  function  of  random  variables  constituting  one  or  more 
samples,  provided  the  function  does  not  depend  on  any  unknown 
parameter  values  (Devore:231).  The  two  major  constructs  of  a  statistic  are 
a  set  of  random  data  and  a  function  to  operate  on  the  random  data.  From 
this  basic  starting  point,  boundaries  on  the  methodology  begin  to  emerge. 
First,  the  statistical  functions  chosen  to  employ  as  an  evaluating  tool 
center  around  the  branch  of  statistics  known  as  analysis  of  variance 
(ANOVA).  The  nature  of  this  research  fits  this  type  of  analysis  very  well. 
As  the  predictive  capability  of  a  model  increases,  the  variance  of  the  error 
of  the  model's  prediction  will  decrease.  The  predictive  accuracy  of  a  model 
is  measured  by  the  variance  of  the  errors  of  that  model.  Second,  the 
limited  available  data  could  not  provide  random  data.  Ideally,  a  random 
sample  would  be  chosen  from  data  on  all  the  software  support  efforts  in 
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the  entire  Air  Force  history.  Limited  data  forced  the  assumption  that  the 
data  collected  would  not  significantly  bias  the  results. 

One  way  to  help  compensate  for  this  weakness  is  to  apply  more  than 
one  statistical  function  to  the  available  data.  Four  statistics,  three  of 
which  are  related  to  ANOVA  techniques,  can  be  applied.  The  first  statistic 
is  the  adjusted  coefficient  of  multiple  determination  (f?^.  The  value  of  this 
statistic  can  be  interpreted  as  the  proportion  of  the  total  variation  of  the 
observed  values*  that  can  be  explained  by  a  multiple  regression  model  and 
adjusted  for  the  degrees  of  freedom^  (Neter:  241).  The  equation  used  to 
calibrate  is  shown  in  equation  3.1. 

Eq  3  1 

SSTO  n  n-p 

i=l 


where  =  coefficient  of  multiple  determination 

SSE  =  sum  of  squares  for  errors 
SSTO  =  sum  of  squares  total 
n  =  number  of  data  points 
p  =  number  of  estimated  parameters  (2) 
i  =  1,  2,  ...  n 
E^^  =  actual  effort 
Eg,i  =  estimated  effort 
E^g  =  average  effort 


An  observed  value  for  this  research  would  be  the  effort  in  man-months  associated  with  a  particular  block 

change. 

2 

The  degrees  of  freedom  can  be  considered  as  to  the  number  of  observations  minus  the  number  of  parameters 
required  to  be  estimated.  Smaller  sample  sizes  have  smaller  degrees  of  freedom. 
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In  equation  3.1,  SSE  is  associated  with  the  variation  of  the  estimation 
errors  of  the  regression  model,  SSTO  is  associated  with  the  total  variation 
of  the  observed  values,  n  is  the  number  of  observations,  and  p  is  the 
number  of  parameters  estimated  by  the  regression  model.  The  possible 
values  for  range  from  0.0  to  1.0.  The  variation  explained  by  the 
regression  is  assumed  to  come  from  a  linear  regression  of  the  historical 
data.  If  the  assumed  regression  is  not  linear,  then  the  regression  must  be 
transformed  into  a  linear  regression  or  a  different  statistic  should  be  used. 
For  example,  COCOMO  uses  an  exponential  model  that  can  be 
transformed  into  a  linear  model  by  taking  the  logarithm  of  both  sides  of 
the  model  equation. 

The  second  statistic  is  the  relative  root  mean  square  error  (RUMS) 
where  error  is  the  difference  between  the  actual  and  estimated  value.  The 
statistic  is  the  ratio  of  the  root  mean  square  over  the  average  actual  value 
(see  equation  3.2). 


where 


RRMS= 


RMS  N 


1  " 

-  E  (£  -E  ) 

.  ^  ^  aa.  tst/ 


avg 


1 

/i,=l 


«Cf, 


RRMS  =  relative  root  mean  square 
RMS  =  root  mean  square 
n  =  number  of  data  points 
i  =  1,  2,  ...  n 
^avg  -  average  effort 
=  actual  effort 
Eg^i  =  estimated  effort 


Eq.  3.2 
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The  third  statistic  is  a  simple  prediction  level.  The  function  is  the 


ratio  of  the  number  of  samples,  k,  whose  magnitude  of  relative  error 
(MRE)  is  less  than  or  equal  to  a  given  percentage,  I,  over  the  total  number 
of  samples,  n  (see  equations  3.3  and  3.4).  Although  the  value  of  the 
statistic  is  simply  a  ratio  of  samples  which  meet  the  minimum  MRE,  the 
statistic  is  easy  to  comprehend  and  does  provide  a  broad  gauge  to  measure 
an  improvement.  The  possible  values  for  the  prediction  function  range 
from  0.0  to  1.0.  A  minimum  value  for  MRE  of  25%,  where  MRE  is 
computed  as  in  equation  3.4,  was  used  in  this  study. 

PRED(/)=-  Eq.  3  3 

n 

where  I  =  prediction  level  percentage 

k  =  number  of  samples  within  prediction  level 
n  -  number  of  samples 


Eq.  3.4 


where  MRE  =  magnitude  of  relative  error 

E^i  =  actual  effort 
=  estimated  effort 

The  last  statistic  is  the  proportion  of  sample  estimates  which  are 
more  accurate  after  functional  calibration.  By  applying  the  above 
statistics  to  each  model  before  and  after  a  calibration,  the  predictive  value 
can  be  assessed.  If  the  predictive  value  of  a  particular  block  change 
sample  improves,  then  it  is  assigned  a  value  of  one.  Otherwise  the  block 


3.12 


change  sample  is  assigned  a  value  of  zero.  The  sum  of  those  samples 
which  improve  after  calibration  can  be  described  as  a  binomial  variable. 
The  proportion  is  the  value  of  the  binomial  variable  divided  by  the  total 
number  of  samples.  If  the  functional  orientation  of  the  model  does  nothing 
to  improve  the  predictive  accuracy  of  the  model,  then  an  improvement 
ratio  near  0.0  is  expected.  A  ratio  near  1.0  would  indicate  improved 
predictive  accuracy. 

Apply  Rejection  Criteria.  For  each  statistic,  a  predetermined 
rejection  criteria  is  needed  to  determine  whether  the  value  of  the  statistic 
supports  or  rejects  the  hypotheses.  The  following  paragraphs  provide 
recommendations  and  a  discussion  of  alternatives  and  potential  problems. 
While  the  choice  of  rejection  values  is  somewhat  arbitrary,  a  pass-fail  line 
is  needed  to  judge  any  improvement  in  the  predictive  capability  of 
functionally  oriented  models. 

For  the  adjusted  coefficient  of  determination,  an  value  of  .9  or 
higher  indicates  that  the  predictive  capability  of  that  model  is  acceptable. 
The  associated  with  a  given  model  can  be  used  to  compare  different 
models  to  determine  which  explains  more  variation.  However,  since 
detailed  input  information  required  for  each  model  may  not  be  available, 
comparing  the  of  one  model  with  high  quality  inputs  to  the  R^  of 
another  model  with  low  quality  inputs  may  not  be  conclusive.  These 
inappropriate  comparisons  may  restrict  the  ability  to  state  which  model  is 
better  than  the  others.  When  trying  to  support  the  main  hypothesis  of 
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improvement,  the  value  of  will  either  rise  or  not  rise.  By  observing  the 
change  in  R^,  an  assessment  of  a  model's  improvement  can  be  made. 

For  the  root  mean  square  error,  an  RRMS  value  of  0.25  or  less  to 
indicate  an  acceptable  model  was  chosen.  Using  this  statistic  to  compare 
two  models  may  be  inconclusive  because  of  different  input  requirements 
for  each  model.  However,  the  statistic  can  be  used  to  determine  whether 
an  individual  model  shows  improvement  after  functional  orientation. 

For  the  percentage  prediction  function,  a  predictive  percentage  of 
within  25%  of  the  actual  value  on  75%  of  the  samples  was  chosen  to 
indicate  an  acceptable  model.  Once  again,  using  this  statistic  to  compare 
two  models  may  be  inconclusive  because  of  different  input  requirements 
for  each  model.  However,  the  percentage  in  the  prediction  zone  can  also 
be  used  to  determine  whether  an  individual  model  shows  improvement 
after  functional  orientation. 

For  the  improvement  ratio,  the  hypothesis  that  the  model  does  show 
improvement  from  functional  orientation  is  accepted  if  the  ratio  supports  a 
0. 1  level  of  significance.  This  rejection  criteria  is  the  main  criteria  for  the 
hypothesis  that  functionally  calibrating  a  model  improves  predictive 
accuracy. 

Condusicm 

This  chapter  described  the  methodology  for  constructing  and 
evaluating  the  two  hypotheses.  The  test  tool  of  the  first  hypothesis  is  a 
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model  which  competes  with  the  four  Air  Force  recommended  models.  The 
design  process  for  this  new  model  and  the  calibration/verification 
methodology  were  presented.  Under  the  second  hypothesis,  four  statistics 
that  could  be  used  to  evaluate  the  four  Air  Force  recommended  models 
within  the  five  functional  categories  were  reviewed.  However,  the  second 
hypothesis  could  not  be  statistically  tested  due  to  a  lack  of  useable  data. 
Suggestions  for  gathering  data  to  validate  this  hypothesis  in  future 
research  are  presented  in  Chapter  V. 
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TV,  Findings 


Chapter  Overview 

This  chapter  summarizes  the  activities  for  evaluating  the  two 
hypotheses.  First,  in  support  of  the  bottom-up  model  construction 
(Hypothesis  1),  Boehm's  COCOMO  maintenance  equations  are  adapted  to 
the  avionics  PDSS  process  to  produce  a  prototype  software  model.  Second, 
in  support  of  our  functional  calibration  (Hypothesis  2),  calibration 
procedures  are  defined  for  the  prototype  model  in  order  to  represent  a  set 
of  historical  data.  Next,  attempts  to  obtain  useful  support  data  from  Air 
Force  organizations  are  reviewed  and  then,  because  of  a  lack  of  useful 
data,  fictional  data  is  generated  as  a  substitute.  Finally,  the  fictional  data 
is  processed  through  the  prototype  model  to  demonstrate  how  the  results 
of  processing  actual  data  might  appear.  The  result  of  the  model  building 
was  a  software  tool  that  could  confirm  or  deny  the  hypotheses  with  actual 
data. 

Hypothesis  1:  Functicnal  Construction  of  a  Software  Estimation  Model 

Constructing  the  prototype  model  occurred  in  three  phases.  The 
first  phase  included  describing  an  avionics  block  change  process  in  object 
oriented  terms.  The  second  phase  consisted  of  a  review  of  the  description 
to  determine  if  it  adequately  reflected  the  existing  software  support 
environment.  After  validation  the  description,  the  third  phase  involved 
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implementing  parts  of  the  description  in  Visual  Basic*  code.  (See 
Appendix  C  for  the  source  code.)  The  Visual  Basic  program  was  a  tool  for 
demonstrating  our  hypotheses  and  a  prototype  for  constructing  a  software 
support  estimation  program. 

Model  Design.  Using  the  object  oriented  design  methodology 
described  in  Chapter  III  to  document  the  block  change  process  was  very 
successful.  To  begin,  we  modeled  a  single  block  change  cycle  as  an  object 
model,  a  functional  model,  and  a  dynamic  model.  The  dynamic  model 
provided  little  insight  into  the  block  change  process;  it  tracked  only 
whether  software  was  currently  in  a  block  change  process  or  not. 

Therefore,  the  dynamic  model  was  removed  from  the  model  set.  The  set 
was  now  composed  of  an  object  model  that  identified  the  important  players 
in  the  block  change  process  and  a  functional  model  that  described  the 
block  change  process  as  a  series  of  subprocesses.  The  final  results  are 
detailed  in  Appendix  D  and  summarized  in  Figure  4.1. 


Visual  Basic  is  a  registered  trademark  of  the  Microsoft  Corporation. 
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Model  I>esigii  Validation.  Our  model  diagrams  served  as  a  common 
reference  for  comparisons  with  support  models  from  existing  avionics  block 
change  process.  AFMC/HQ  recommended  discussing  the  support  process 
with  a  process  action  team  (PAT)  at  Sacramento  ALC  who  had  completed  a 
detailed  review  of  the  entire  PDSS  process  in  October  1990.  The  PAT 
compiled  a  detailed  report  using  a  computer  aided  software  engineering 


4.3 


(CASE)  design  tool  and  structured  system  design  techniques  to  document  a 
PDSS  process  (Talbot).  Structured  design,  a  predecessor  to  object  oriented 
design,  was  compatible  to  our  model  for  direct  comparison.  Comparing  the 
structured  analysis  data  flow  diagrams  prepared  by  the  PDSS  PAT  (see 
Figure  4.2)  to  our  object  oriented  functional  models  (see  Figure  4. 1),  which 
used  the  same  notation,  was  direct  and  simple.  The  models  correlates  well 
with  only  a  few  minor  differences. 


We  contacted  Sacramento  ALC  to  reconcile  the  differences  between 
the  PDSS  PAT  model  and  our  block  change  model.  The  differences  stem 
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from  an  assumption  made  by  the  PAT;  their  model  assumed  successful 
completion  of  all  software  support  activities  on  the  first  try.  The  PAT 
model  did  not  show  any  rework  or  waiver  paths.  Since  the  block  change 
model  had  no  assumption  of  success,  it  included  rework  and  waivers  as 
alternative  paths  from  both  the  integration  and  flight  test  processes  (see 
Figure  4.1).  Table  4.1  is  a  comparison  of  the  single  block  change  cycle 
model  to  the  PAT  model  and  the  MIL-HDBK-347  process  description.  The 
close  correlation  of  the  our  model  to  the  PAT  model  was  tacit  confirmation 
of  our  model. 
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Table  4.1 


Block  Change  Process  Model  Comparison 


HYPOTHESIS  1 
Block  Change 
Process  Model 

SACRAMENTO  ALC 
PAT  Process 

MIL-HDBK-347 

Process 

1)  Estimate  Effort 

1)  Evaluate  Changes 

1)  Initial  Analysis 

2)  Prioritize  Board 

3)  CCB  Process 
— 

4)  Develop  Changes 

2)  Analyze  System 
Requirement 

2)  Develop  Software 

3)  Analyze  Software 
Requirement 

4)  Design  Software 

5)  Modify  Source  Code 

6)  Integrate  Software 

3)  System  Integration 
and  Test 

5)  Ground  Integration  Test 

7)  Integration  Testing 

6)  Flight  Test 

7)  Waiver  Board 

(Not  Modeled) 

(Not  Modeled) 

8)  Rework 

(Not  Modeled) 

(Not  Modeled) 

9)  Reproduce  Tape 

8)  Produce  Modification 
Package 

4)  Product  Logistics 

10)  Field  Change 

Model  Construction. 

Choosing  a  Laugtu^.  Confirming  the  block  change  support 
model  signaled  the  clearance  to  translate  the  model  description  into 
software  code.  We  chose  to  code  our  model  in  the  Visual  Basic 
programming  language  for  several  reasons.  The  foremost  reason  for 
choosing  Visual  Basic  was  the  simple  and  understandable  language 
syntax.  The  mathematical  algorithms  implementing  the  support  model 
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were  easy  to  comprehend  because  of  the  simple  syntax.  Another  reason  for 
selecting  Visual  Basic  was  the  availability  of  pre-written  software 
components,  called  controls,  which  eased  our  programming  task.  These 
controls  also  provided  an  excellent  prototyping  environment  for  quickly 
trying  different  possibilities.  The  last  reason  for  choosing  Visual  Basic 
was  the  supplemental  software  included  with  the  Visual  Basic  package 
which  had  the  capability  to  create  executable  and  distributable  programs. 
Thus,  anyone  who  wished  to  run  our  prototype  could  obtain  free  copies. 

The  Visual  Basic  language  proved  to  be  a  capable  and  flexible  language  for 
prototyping. 

Refining  the  Model.  Our  intention  of  programming  with 
Visual  Basic  was  not  to  program  the  entire  PDSS  process  but  to  program 
only  that  portion  of  the  process  needed  to  test  the  hypotheses.  The  basic 
approach  was  to  adapt  the  maintenance  portion  of  Boehm’s  COCOMO 
model  to  reflect  block  change  characteristics  cited  in  the  literature  review 
and  the  PDSS  process  as  modeled  in  Figure  4.1.  The  model  accepted  a 
development  code  size,  an  expected  change  in  code  size,  and  a  support 
attributes  as  a  starting  point  to  iterate  several  successive  block  changes. 
While  Boehm’s  COCOMO  model  used  annual  change  traffic  (ACT)  to 
represent  the  expected  change  size,  the  prototype  introduced  another  size 
measurement  called  block  change  traffic  (BC'T).  Furthermore,  while  the 
COCOMO  model  did  not  explicitly  vary  any  attributes  during  successive 
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block  changes,  the  prototype  model  altered  some  attributes  to  account  for 
temporal  changes  from  block  change  to  block  change. 

Block  Change  Size.  As  stated  in  Chapter  II,  Boehm  described 
the  expected  change  in  code  size  during  one  year  of  support  activity  as  the 
ratio  of  the  expected  number  of  added  and  modified  delivered  source 
instructions  (DSI)  over  the  total  number  of  DSI.  This  ratio,  called  annual 
change  traffic  (ACT),  was  the  predecessor  to  the  protot3T?e  ratio,  BCT. 

BCT  was  the  ratio  of  equivalent  DSI  (EDSI)  over  the  total  number  of  DSI. 
Note  that  while  the  prototype  EDSI  was  conceptually  the  same  as  EDSI 
from  Boehm's  conversion  cost  estimating  (both  are  an  equivalent  size  and 
are  weighted),  the  prototype  EDSI  was  not  calculated  in  the  same  manner. 
The  model  did  not  use  Boehm's  conversion  cost  estimating,  so  all  future 
references  to  EDSI  mean  the  prototype  EDSI,  not  Boehm’s.  The  model 
EDSI  was  the  weighted  sum  of  the  expected  number  of  added,  modified, 
and  deleted  DSI  for  a  particular  block  change.  While  Boehm’s  ACT  did  not 
include  deleted  DSI  or  weight  any  code,  the  model  EDSI  included  lines  of 
deleted  code  and  weighted  the  three  change  categories.  Weighing  the 
expected  added,  modified,  and  deleted  lines  of  code  consisted  of  multiplying 
each  change  category  by  values  from  SOFTCOST*R's  reused  code 
weightings  in  Table  2.2.  Since  the  prototype  did  not  distinguish 
differences  between  modules  and  lines,  it  added  the  weightings  for  module 
and  line  deleted  and  for  modules  and  lines  modified  or  changed.  The 
prototype  model  also  ignored  the  retested  modules  because  avionics  testing 
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effort  was  better  estimated  by  other  means.  The  resulting  equation  for 
EDSI  is  shown  in  equation  4.1. 

EDSl=0.53*KDSl^^.Sl*KDSI^^*026*ICDSJo^  Eq.  4  1 

where  KDSI  =  thousands  of  delivered  source  instructions 
EDSI  =  equivalent  KDSI 

This  definition  of  EDSI  was  an  attempt  to  better  define  the  block 
change  size.  Remember  that  the  major  correlation  in  predicting  effort  was 
between  size  and  effort.  As  stated  in  Chapter  II,  better  predictions  in  size 
estimates  will  produce  better  effort  estimates.  Although  the  code  size 
during  support  was  not  exactly  reused  code  as  used  by  SOFTCOST-R, 
reused  code  was  similar  enough  to  redeveloped  (support)  code  to  warrant 
the  reused  weightings  as  a  starting  point  for  a  better  estimation  of  size. 

Tetnporal  Chaises.  With  an  adequate  description  of  a  block 
change  size,  we  described  the  temporal  effects  for  each  block  change.  The 
front  and  back  ends  of  the  bath-tub  curve,  as  described  in  Chapter  II,  can 
accompany  successive  block  changes.  These  temporal  effects  could  come 
from  at  least  four  potential  sources;  learning,  size  growth,  memory  and 
throughput  utilization,  and  entropy.  Each  of  these  sources  is  discussed  in 
the  following  paragraphs. 

The  first  temporal  effect  encountered  in  the  support  phase  of 
software  was  the  learning  effect.  The  learning  effect  was  a  direct  result  of 
support  personnel  working  with  software  and  its  documentation.  As  these 
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personnel  increased  their  knowledge  of  the  support  software,  they  could 
better  identify  errors  and  more  efficiently  correct  them.  However,  the 
learning  effect  did  not  continue  throughout  the  entire  PDSS  phase. 
According  to  literature  cited  in  Chapter  II,  learning  lasted  from  three  to 
six  years  (SYSCON:44).  A  possible  contributor  to  this  time  window  is 
personnel  turnover.  When  software  personnel  depart  from  a  position,  new 
personnel  must  replace  them,  but  these  new  personnel  are  not  as 
knowledgeable  or  experienced.  The  departing  personnel  take  with  them 
much  of  their  learning,  and  that  learning  is  lost. 

The  learning  curve  implies  a  relationship  between  the  complexity  of 
the  software  and  the  rate  at  which  learning  occurs;  more  complex  software 
should  take  longer  to  learn.  The  prototype  did  not  include  a 
complexityAearning  relationship  because  no  literature  sources  were  able  to 
quantify  it. 

The  prototype  model  did  introduce  a  learning  effect  model  by 
decreasing  COCOMO's  analyst  experience  (AEXP)  and  language  experience 
(LEXP)  multipliers  for  the  first  six  block  changes.  Following  the  curve 
suggested  by  the  SYSCON  data  in  Table  2.5,  the  prototype  multiplied  the 
AEXP  and  LEXP  attributes  by  values  less  than  or  equal  to  1.0.  The 
equation  that  calculated  these  values,  equation  4.2,  came  from  the 
averaged  exponents  of  the  design  and  development  equations  in  Table  2.5 
(see  Appendix  E  for  derivation).  Equation  4.2  discarded  the  coefficients 
from  Table  2.5  to  force  an  initial  multiplier  of  1.0  for  block  change  zero 
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(development).  Succeeding  block  change  multipliers  were  all  less  than  1.0, 
resulting  in  an  effort  reductions,  and  were  applied  equally  to  AEXP  and 
LEXP  for  the  first  six  block  change  cycles.  In  order  to  use  the  learning 
effect  relationship,  equation  4.2  assumed  each  block  change  was  one  year 
in  length.  A  change  to  the  block  change  duration  would  require 
additional  calculations  to  maintain  the  documented  relationship. 

Eq  4.2 

where  LE  =  learning  effect 

3C;  =  block  change  number 

i  =  1,  2,  ..  6 

The  second  temporal  effect  encountered  in  support  was  size  growth 
in  the  software  being  maintained.  As  software  was  modified,  it  usually 
grew  in  size.  Size  was  important  to  track  because  estimators  needed  to 
know  how  much  of  the  target  computer  memory  remained  unused  in  order 
to  estimate  an  increase  in  the  support  effort  per  line  of  code.  A  larger  code 
size  required  more  effort  per  line  to  support. 

The  prototype  model  encompassed  a  method  to  increase  the  size  of 
the  support  code  in  a  realistic  manner.  The  term  realistic  means  that  the 
model  complied  with  the  constraint  that  size  cannot  grow  beyond  100% 
memory  capacity.  Once  software  grows  to  over  95%  of  available  memory, 
the  model  limited  the  size  growth  for  successive  block  changes  to  one-half 
the  remaining  memory.  Therefore,  in  later  block  changes,  the  software 
size  grew  very  slowly  and  asymptotically  towards  100%. 
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The  specifics  of  size  growth  were  implemented  as  a  two  part 
process.  First,  an  estimator  provided  a  development  total  code  size  and  a 
memory  utilization  percentage.  Next,  the  number  of  deleted  and  added 
lines  of  code  for  ea,ch  block  change  were  respectively  subtracted  and  added 
to  the  previous  block  change  size.  The  result  was  a  changing  total  code 
size  that  tjrpically  increased  in  size  since  the  number  of  added  lines  was 
usually  greater  than  the  number  of  deleted  lines. 

As  the  total  size  of  the  code  increases,  it  can  affect  the  next  set  of 
temporal  effects,  memory  and  throughput  utilization.  The  prototype  model 
treated  these  two  effects  as  one  because  of  their  common  characteristics. 

As  the  utilizations  increase,  they  both  increase  the  required  support  effort 
and  they  both  are  limited  to  100%.  Aircraft  avionics  systems  have  definite 
memory  and  throughput  limits  that  can't  be  exceeded.  As  the  memory  and 
throughput  limits  are  approached,  support  programmers  must  carefully 
engineer  the  code  modifications  to  remain  below  the  memory  and 
throughput  limits.  When  adding  code  near  the  memory  and  throughput 
limits,  software  support  programmers  must  choose  size  efficiency  over  code 
simplicity  and  clarity.  The  resulting  code  is  more  complex  than  code  at 
lower  memory  and  throughput  limits.  This  complex  code  requires  greater 
intellectual  investment  and  more  time  to  create.  The  code  is  also  more 
error  prone.  The  prototype  model  included  both  temporal  effects  in  two 
ways.  The  model  set  how  the  level  of  utilization  affects  one  particular 
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block  change  and  how  the  utilization  level  changes  during  sequential  block 
changes. 

For  one  particular  block  change,  the  levels  of  memory  and 
throughput  utilization  could  affect  the  original  COCOMO  attribute 
multipliers  of  the  main  storage  constraint  (STOR)  and  the  execution  time 
constraint  (TIME)  (see  Table  2.7).  Boehm  defined  the  STOR  rating  as  a 
percentage  of  main  storage  expected  to  be  used  by  the  subsystem  and  any 
other  subsystems  consuming  the  main  storage  resources  (Boehm:410)  and 
the  TIME  rating  as  the  percentage  of  available  execution  time  expected  to 
be  used  by  the  subsystem  and  any  other  subsystems  consuming  the 
execution  time  resource  (Boehm: 401).  Both  of  the^  .  definitions  fit  nicely 
with  the  objective  of  describing  the  effects  of  memory  and  throughput 
utilization'.  Although  Boehm  already  quantified  the  affects  of  these 
attributes  with  a  set  of  four  discrete  multipliers,  the  prototype  altered  the 
development  attributes  with  a  continuous  function  based  on  the  utilization 
percentage.  The  coefficients  and  exponents  of  the  memory  fill  and  timing 
fill  relationships  of  the  design  and  development  phases  from  the  SYSCON 
report  (Table  2.3)  were  averaged  to  produce  a  composite  relationship  that 
covered  support  design  and  development.  The  resulting  equations 
provided  a  multiplier  to  apply  against  the  development  STOR  and  TIME 
attributes  as  the  memory  and  timing  percentages  varied  during  block  cycle 

'  The  prototype  model  considered  available  throughput  as  the  mathematical  inverse  of  available  execution 
time.  Both  degrade  at  the  same  rate. 
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changes.  Both  equations  4.3  and  4.4  produced  a  multiplier  of  1.0  at  a 
utilization  rate  near  62%  utilization,  so  the  model  used  65%  utilization  as 
the  threshold  for  applying  the  equations.  At  utilization  rates  of  65%  or 
more,  the  equations  produced  multipliers  greater  than  1.0  to  represent  an 
increased  effort. 

M£= 1.905  *(%AfeinoryFi«/100)‘*“ 
where  ME  =  memory  effect 

TE=l.S2i%nroughput/mY^ 

where  TE  =  throughput  effect 

At  95%  memory  and  throughput  utilization  ,  '  oth  equations  combined  to 
yield  a  3.01  multiplier.  This  3.01  value  implied  that  the  effort  required  at 
95%  utilization  rate  is  about  three  times  greater  than  an  effort  at  less 
than  65%  utilization.  This  3.01  value  also  compares  favorably  with  the 
95%  result  of  3.78  shown  in  Table  2.4. 

Once  the  memory  and  throughput  utilization  effects  were 
established,  we  determined  how  the  utilization  would  vary  from  block 
change  to  block  change.  Because  of  an  absence  of  historical  time-series 
utilization  rates  for  software  support,  the  prototype  substituted  a  simple 
rule:  both  memory  and  throughput  utilization  varied  directly  with  size 
growth  as  described  above.  Although  this  rule  applied  to  memory 
utilization,  it  did  not  precisely  describe  throughput  utilization.  For 
throughput.  The  model  accepted  this  imprecisio.^  in  order  to  keep  the 
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model  simple.  However,  since  neither  memory  nor  throughput  utilization 
can  exceed  100%,  the  prototype  limited  utilization  growth  to  one-half  the 
remaining  utilization  when  utilization  exceeded  95%. 

Size  growth,  along  with  dwindling  available  memory  and 
throughput,  also  contributed  to  the  fourth  bath-tub  curve  effect,  design 
deterioration.  We  preierred  the  term  design  entropy  although  none  of  the 
literature  reviewed  used  this  term.  The  word  entropy  highlights  an 
irreversible  nature  of  design  degradation  as  code  is  iterated  through 
multiple  block  changes.  We  suspected  design  entropy  was  primarily  a  by¬ 
product  of  making  adaptive  changes  to  software.  Later  in  the  PDSS  life 
cycle,  as  memory  and  throughput  reserves  dwindle,  design  entropy  can  be 
accelerated  by  the  necessity  to  code  for  efficiency  instead  of  simplicity. 
Efficient  and  complex  code  often  leads  to  complex  and  degraded  designs. 
Another  contributor  to  design  entropy  could  occur  firom  poor  software 
engineering  practices  during  PDSS.  Whatever  the  cause,  the  result  was 
the  same.  The  design  lost  flexibility,  and  the  original  structure  of  the 
software  decayed  as  changing  requirements  are  implemented.  How 
quickly  design  entropy  affected  support  depended  on  the  original  design. 
Simple,  well-engineered,  and  well-documented  code  that  is  built  and 
maintained  with  object  oriented  or  structured  design  techniques  should  not 
show  the  effects  of  entropy  as  early  as  complex,  poorly-designed  code 
(spaghetti  code).  We  faced  a  challenge  trying  to  express  and  quantify  this 
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concept.  As  a  minimum,  two  components  were  needed  -  entropy  timing 
and  magnitude  of  impact. 

With  no  data  or  literature  quantifying  the  timing  or  magnitude  of 
design  entropy,  we  resisted  the  temptation  to  create  a  relationship  out  of 
thin  air  and,  instead,  left  it  out  of  the  model.  The  model  relied  on  the  size 
growth  and  the  reduction  of  available  memory  and  throughput  to  capture 
the  upward  sloping  portion  of  the  bath-tub  curve. 

When  all  of  the  effects  from  this  section  were  combined  into  one 
equation,  the  result  was  equation  4.5. 

aiKDSli*  (U)*LE*ME*TE  EQ  4.5 

where  MM  =  estimated  man-months 
BCT  -  block  change  traffic 
a  -  calibration  coefficient 
h  =  calibration  exponent 

KDSI  -  thousands  of  deliver  sources  lines  of  code 
77=  product  of  the  COCOMO  multipliers 
LE  =  learning  effect 
ME  =  memory  effect 
TE  =  throughput  effect 

Hypothesis  2:  Functional  Calibration  to  Improve  Model  Accuracy 

Although  equation  4.5  adequately  described  the  general  shape  of  a 
time-series  of  support  efforts  for  a  single  unit  of  code,  the  coefficient 
parameter,  o,  and  the  exponent  parameter,  6,  needed  accurate  values  so 
the  equation  could  produce  the  best  estimates  possible.  Finding  the  best 
parameter  values  for  a  particular  scenario  was  done  through  calibration 
from  historical  data.  It  was  possible  to  calibrate  equation  4.5  using  the 
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calibration  technique  outlined  in  Chapter  II  (equations  2.14  and  2.15)  by 
including  BCT  as  shown  in  equation  4.6. 


where  a  =  coefficient  parameter 
b  =  exponent  parameter 
i  =  1,  2,  ..  number  of  block  changes 
KDSI  =  thousands  of  DSI  total  code  size 
MM  =  man-months  of  effort 
BCT  =  block  change  traffic 

n  =  product  of  adjustment  factors  and  temporal  effects 
Q  -  temporary  variable  for  future  equations 


To  begin  the  calibration  process,  the  prototype  model  used  a  set  of 
historical  MM,  BCT,  and  FI  values  to  calculate  a  set  of  Q  values.  Each  Qj 
value  represented  an  effort  for  correlation  against  a  corresponding  block 
change  size.  Although  KDSIi  and  in  equation  4.6  appeared  to  correlate 
total  size  and  effort,  the  real  correlation  was  between  EDSI  and  effort. 


BCT,  which  was  contained  in  EDSI,  could  be  considered  as  a  scaling  factor 
to  make  Q,  appear  as  a  typical  development  magnitude  for  the  total 
development  size.  (Remember  the  MMj  value  only  included  effort  for  a 
block  change,  not  an  entire  development.)  In  order  to  correlate  these 
points  linearly  (no  exponents),  equation  4.6  can  be  transformed  with  a 
logarithmic  function  to  produce  equation  4.7. 
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log(a)  +b*logiKDSI)  =log(Oj) 


Eq.  4.7 


Equation  4.7,  in  the  form  of  a  line,  permitted  a  least  squares  regression  to 
a  set  of  data  points.  The  resvilts  of  this  regression  were  values  for  a  and  b 
which  describe  the  line  that  best  predicts  a  Q  value  (effort)  given  a  KDSI 
value  (size). 

The  continuation  of  the  calibration  process  included  building 
calibration  equations  similar  to  those  from  Chapter  II  (equation  2.14)  to 
arrive  at  equation  4.8.  (Remember  that  Q  contains  BCT.) 


n 

a.=  S  logiKDSI)i 
i=l 

S  WogiKDSI)?  . 

i=l  ^ 

S  logiQ.) 
i=l 
n 

dr  S  log«^)log(«)57),. 
i=l 

where  =  the  number  of  data  points  (block  changes) 

a„  Oj  =  temporary  variables  for  future  equations 
dg,  dj  =  temporary  variables  for  future  equations 

Next,  equation  2.15  can  be  applied  to  calculate  o  and  b. 


log(a)= 


^dp-aid^ 


Eq.  4.9 
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From  a  mathematical  standpoint,  equations  4.8  and  4.9  were  similar 
to  the  COCOMO  calibration  equations  from  Chapter  II  and  were 
straightforward  to  calculate.  Keeping  the  exponential  form  of  Boehm's 
equations,  these  equations  captured  a  relationship  between  the  size  of  the 
baseline  code  (KDST)  and  the  size  of  the  change  being  made  (EDSI).  This 
relationship  implied  that  supporting  a  given  number  of  DSI  in  a  large 
program  required  more  effort  than  supporting  the  same  number  of  DSI  in 
a  small  program. 

Interpreting  the  meaning  of  this  support  calibration  depended  on 
the  data  used  to  calibrate  the  model.  If  data  was  from  a  single  PDSS 
lifecycle,  then  the  calibration  would  capture  the  long-term,  stable 
characteristics  within  that  lifecycle.  We  labeled  this  case  a  horizontal 
calibration.  During  a  development  time  frame,  this  type  of  calibration 
would  be  useful  for  predicting  total  lifecycle  cost  from  equations  calibrated 
to  previous  support  lifecycles.  During  a  support  time  frame,  this  type  of 
calibration  would  be  useful  for  predicting  the  next  block  change  from 
equations  calibrated  to  previous  block  changes.  However,  these  calibration 
techniques  might  be  inappropriate  if  the  attribute  adjustment  factors  did 
not  follow  a  bath-tub  curve.  This  last  scenario  may  be  better  suited  for  the 
case  we  labeled  as  vertical  calibration. 

Vertical  calibration  uses  data  from  the  i***  block  change  cycle  from 
different  software  products  for  calibration.  This  calibration  could  capture 
common  characteristics  across  similar  systems  at  the  i^**  block  change  and, 


4.19 


presumably,  could  be  used  for  predicting  the  i^*  block  change  cost  of  a 
similar  system.  Vertical  calibration  is  equivalent  to  calibrating  the 
development  equation  using  development  data  because  the  historical  data 
comes  from  different  software  systems.  However,  there  is  no 
developmental  equivalent  of  horizontal  calibration. 

Which  calibration  works  the  best  for  a  given  scenario?  There  was 
insufficient  time  or  data  to  experiment  with  horizontal  versus  vertical 
calibration.  However,  given  sufficient  data,  this  comparison  could  be 
accomplished  using  Hypothesis  2  (functional  calibration  of  existing  models) 
methodology  and  the  model  comparison  methodology. 

In  an  attempt  to  validate  the  calibration  algorithm,  we  entered 
Boehm's  database  (Boehm:496)  into  the  prototype  and  calibrated  each 
mode.  A  re-derivation  of  the  coefficient  and  exponent  values  for  all  three 
COCOMO  modes  was  expected.  However,  as  shown  in  Table  4.2,  the 
results  did  not  duplicate  the  coefficient  or  exponent  for  the  organic  and 
semi-detached  modes.  The  embedded  mode  values  were  much  closer. 


Table  4.2 

Calibration  Comparison 


Mode 

Boehm  Parameters 

Prototype  Parameters 

Organic 

3.2 

1.05 

4.3000 

0.9337 

Semi-detached 

3.0 

1.12 

3.1855 

1.1033 

Embedded 

2.8 

1.20 

2.7838 

1.2090 

All  data 

- 

- 

2.8309 

1.1581 
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One  possible  reason  for  the  differences  shown  in  Table  4.2  could  be 
rounding  or  truncation  of  the  database  numbers  published  in  Boehm's 
book.  For  example,  project  numbers  (PN)  4,  8,  14,  16,  20,  24,  31,  33,  34, 
and  35  had  adjustment  factor  products  (IT)  more  than  1%  different  than 
the  actual  product  of  the  adjustment  factors  (LANG  through  RVOL) 
(Boehm:496).  Although  the  difference  seemed  small,  these  differences 
were  well  within  the  resolution  of  the  published  numbers.  The  different 
results  could  also  be  a  result  of  Boehm  adjusting  the  coefficients  and 
exponents  based  on  his  personal  knowledge  and  experience. 

Data 

In  order  to  calibrate  the  model  equations,  we  attempted  to  obtain 
actual  historical  data  from  several  aircraft  support  lifecycles.  The  data 
collection  efforts  began  in  October  1992  by  contacting  representatives  from 
each  of  the  combat  aircraft  listed  in  Chapter  I  (page  1.12).  The  initial 
contacts,  from  the  System  Project  Offices  (SPOs)  at  Wright-Patterson  AFB, 
lead  us  to  the  Air  Logistics  Centers  at  Warner-Robins,  Ogden,  Oklahoma 
City,  and  Sacramento.  Except  for  Warner-Robbins,  we  established  good 
contacts  at  the  ALCs,  mailed  to  them  our  data  forms  (see  Appendix  B), 
and  received  a  75%  response  rate  against  our  targeted  platforms.  The 
forms  were  mailed  to  ALC  engineers  involved  in  software  support 
management  for  the  F-16,  the  B-52,  the  F-111,  and  the  B-1.  We  received 
no  response  for  the  B-1  but  received  an  unsolicited  response  for  the  E-3. 
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Data  CoUectioo.  Conversations  with  the  ALC  contacts  indicated 
that  the  bulk  of  the  needed  data  resided  in  local  databases.  Despite  these 
promising  beginnings,  the  data  received  was  surprising.  Given  the  slow 
response  time  and  the  sparseness  of  data,  the  local  databases  apparently 
were  not  readily  accessible  or  useable  and  did  not  contain  the  needed  data. 
Eleven  data  points  were  received,  but  only  four  were  useful. 

Table  4.3  is  a  summary  of  the  change  size/effort  data  received.  The 
data  points  are  shown  in  random  order  and  are  labeled  A  -  K. 

Table  4.3 
Actual  Data 


LABEL 

SLOG 

CHANGED 

SLOC  AT 
START  OF 
CYCLE 

MANHOURS 

DURATION 

(MONTHS) 

A 

not  available 

not  available 

33,405’ 

13’ 

B 

32,300 

19,500 

12 

0 

13,400 

2,976 

16 

D 

not  available 

17,580 

12 

600 

13,000 

1,275 

11 

F 

36,626 

not  available 

414,484 

29 

250 

11 

H 

not  available 

not  available 

27,622’ 

12’ 

1 

not  available 

not  available 

10,175’ 

8’ 

20 

41,000 

2,325 

11 

K 

31,888 

not  available 

398,105 

43’ 

Estimated  data  not  actual. 
Usable  data  points. 
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Since  some  participants  requested  that  their  data  not  be  traceable  to  them, 
the  original  data  sheets  were  not  printed  in  this  thesis. 

Only  four  of  the  eleven  data  points  contained  suitable  size  and  effort 
information.  Unfortunately,  four  data  points  were  insufficient  to  validate 
Hypothesis  1  (functional  bottom- up  construction  of  a  software  cost 
estimation  model)  or  Hjqjothesis  2  (functional  top-down  calibration  of  a 
statistically-based  software  cost  estimation  model).  In  most  cases,  sample 
sizes  of  at  least  10  or  more  are  necessary  to  obtain  meaningful  statistical 
confidence  intervals  and  to  evaluate  the  statistical  measures  in  Chapter 
III.  Obtaining  larger  samples  required  generating  a  sample  database. 

The  last  historical  data  came  in  May  1993.  At  that  time,  we  stopped 
trying  to  collect  additional  data  to  validate  our  hypotheses  and  redirected 
our  efforts  toward  generating  sample  data  to  demonstrate  the  hypotheses. 

Data  Generation.  To  generate  realistic  data  for  the  support  model, 
we  invoked  the  model  itself.  The  model,  an  enhanced  adaptation  of 
Boehm's  COCOMO  maintenance  model,  could  be  considered  a 
mathematical  function  with  multiple  inputs  (size  and  attribute  factors) 
and  a  single  output  (block  change  effort).  The  basic  concept  was  to 
generate  a  perfect  set  of  output-input  pairs  and  then  add  a  known 
variation  onto  the  effort.  The  resulting  fictional  sample  could  then  be  used 
to  demonstrate  both  hypotheses. 

Starting  with  the  basic  concept,  we  programmed  a  software  module 
that  used  the  our  support  equations  to  generate  random  data  points.  The 
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first  step  was  to  generate  values  simulating  the  result  of  a  random 
development  product.  This  was  equivalent  to  generating  all  the  values  for 
the  right-hand  side  of  the  intermediate  COCOMO  maintenance  equation 
discussed  in  Chapter  II  (equation  2.11).  The  desired  effort-size 
relationship  was  the  basis  for  selecting  values  for  a  coefficient,  a,  and  an 
exponent,  b.  Next,  a  random  number  function  produced  a  development 
product  size,  KDSl,  and  each  of  the  adjustment  attributes,  C,j.  The 
prototype  calculated  three  temporal  effects,  LE,  ME,  and  TE,  based  on  the 
block  change  number  and  then  scaled  the  AEXP,  LEXP,  STOR,  and  TIME 
adjustment  attributes.  After  scaling,  the  prototype  applied  three 
percentages,  representing  the  size  of  added,  modified,  and  deleted  code  for 
a  block  change,  to  the  KDSI  size  to  produce  a  block  change  size  in  units  of 
KDSI.  The  model  then  weighted  these  three  sizes  according  to  equation 
4. 1  to  arrive  at  EDSI.  Next,  dividing  EDSI  by  KDSI  produced  BCT.  At 
this  point,  all  the  values  required  for  the  right-hand  side  of  equation  4.5 
were  calculated,  so  the  prototype  calculated  the  MM,  labeled  MM, „j,  for 
the  left-hand  side  of  the  equation. 

By  calculating  an  effort  for  each  set  of  inputs  associated  with  a 
block  change,  the  prototype  completed  the  first  half  of  the  basic  concept, 
generating  a  perfect  set  of  output-input  pairs.  For  the  second  half  of  the 
basic  concept,  adding  a  known  variation  onto  the  efforts,  the  prototype 
applied  a  random  number  function.  The  function  accepted  the  mean  and 
standard  deviation  of  a  desired  normal  distribution  and  returned  an 
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appropriate  random  deviate.  A  mean  of  zero  for  all  deviate  calculations 
insured  an  even  spread  of  positive  and  negative  deviate  values.  Our  first 
inclination  was  to  add  the  resulting  deviate  directly  to  the  estimated  block 
change  effort,  but  we  realized  that  adding  deviates  to  effort  in  the 
exponential  domain  was  wrong.  Since  calibration  is  based  upon  a  linear 
regression  in  the  logarithmic  domain,  the  perfect  input-output  pairs  had  to 
be  converted  to  the  logarithmic  domain  (as  shown  by  equation  4. 10)  before 
adding  the  deviates. 


=ln(flC7)  +ln(a)  +f>*ln(H:DS7) +Sln(II)  Eq.  4. 1 0 

After  generating  a  normally-distributed  random  deviate,  the  prototype 
added  the  deviate  to  the  converted  block  change  effort.  In  a  sense,  adding 
the  random  deviate  is  like  adding  noise  to  a  perfect  block  change  effort  in 
order  to  introduce  some  realism.  The  resulting  effort  was  labeled 
^^simuiaied  shown  in  equation  4.11. 


^noise 


Eq  4.11 


Finally,  the  prototype  model  transformed  the  randomii.ed  effort  back  to  the 
exponential  domain  by  taking  the  inverse  of  the  natural  logarithm  (e”^. 

The  generated  data  could  now  be  treated  as  historical  data  for  the 
calibration  and  evaluation  of  the  model. 
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Demonstration 


Using  the  data  generation  methodology,  the  prototype  model  created 
data  to  demonstrate  both  hypotheses.  By  programming  the  methodology 
into  software  using  the  Visual  Basic  language,  the  model  created  the  data 
sets  printed  in  Appendix  F.  The  data  requirements  of  the  hypotheses  were 
different  and  necessitated  two  different  databases.  The  simplest  database 
supported  the  second  hypothesis,  functional  calibration.  The  more  complex 
database  supported  the  first  hjqjothesis,  construction  of  a  bottom-up  cost 
model.  The  following  description  for  each  database  generation  begins  with 
the  Hypothesis  2  (functional  calibration)  database  generation. 

Hypothesis  2.  The  functional  calibration  hypothesis  was 
demonstrated  using  families  of  data  points  with  each  family  member 
generated  from  the  same  coefficient/exponent  combination.  Using  the 
Create  Database  function  in  the  software,  the  prototype  generated  five 
families  of  20  data  points  each.  Each  family  had  a  different 
coefficient/exponent  combination.  By  selecting  a  family  or  group  of 
families,  we  were  able  to  simulate  how  functional  calibration  might 
improve  software  effort  estimation  and  demonstrate  the  model  comparison 
methodology  described  in  Chapter  III. 

The  prototype  constructed  the  composite  database  of  block  change 
families  with  inputs  shown  in  Table  4.4. 
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Table  4.4 


Input  Parameters  for  Composite  Database 


Parameter 

Value 

Number  of  Block  Changes  per  Category 

20 

Development  KDSI  Size 

100 

Adjustment  Factor  Standard  Deviation 

0.17 

Code  Affected 
per  Block  Change 

Percent  Added 

6 

Percent  Modified 

10 

Percent  Deleted 

2 

Percent  Std  Dev 

0.3 

Communication 

Identification 

Coefficient 

2.40 

Exponent 

1.05 

Effort  Std  Dev 

0.4 

Navigation 

Sensors 

Coefficient 

2.70 

Exponent 

1.16 

Effort  Std  Dev 

0.4 

Core 

Avionics 

Coefficient 

2.70 

Exponent 

1.16 

Effort  Std  Dev 

0.4 

Electronic 

Combat 

Coefficient 

3.10 

Exponent 

1.28 

Effort  Std  Dev 

3 

Offensive 

Sensors 

Coefficient 

3.20 

Exponent 

1.36 

Effort  Std  Dev 

0.4 

Note  that  Table  4.4  navigation  and  core  avionics  categories  were  set  to  the 
same  base  equation  (coefficient  and  exponent)  and  that  the  standard 
deviation  for  the  electronic  combat  category  was  much  higher  than  the 
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other  categories.  After  accepting  data  according  to  the  inputs  in  Table  4.4, 
the  prototype  produced  the  data  shown  in  Figure  4.3. 


The  data  in  Figure  4.3  had  many  sources  of  variation.  The  first  source  of 
variation  came  from  the  attribute  adjustment  factors,  which  accounted  for 
a  large  portion  of  the  total  variation.  The  second  source  of  variation  came 
fi:om  random  proportions  of  the  block  change  code  additions,  modifications, 
and  deletions.  The  last  source  of  variation  came  fi’om  the  effort  standard 
deviation  assigned  to  each  category.  The  lone  data  point  fiom  the 
electronic  combat  (EC)  category  was  the  result  of  the  high  variation 
assigned  to  this  category. 

When  the  variation  from  the  attribute  adjustment  factors  was 
removed,  the  prototype  produced  a  normalized  database.  With  the  product 


4.28 


of  the  adjustment  factors  (0)  divided  out  (normalizing),  the  underljdng 
relations  of  the  data  were  much  easier  to  see.  Figure  4.4  shows  the  data 
from  Figure  4.3  after  normalization. 


Figure  4.4  •  Normalized  Composite  Database 


Notice  that  many  of  the  data  points  if  Figure  4.4  have  aligned  along 
imaginary  lines.  We  exploited  this  tendency  by  separating  out  these 
points  and  recalibrating  to  only  these  points.  Also,  many  of  the  data 
points  have  lower  effort  values  because  they  have  a  total  product 
adjustment  (FI)  greater  than  1.0.  To  compensate  for  the  change  in  scale, 
the  prototype  enlarged  the  data  scale  by  reducing  the  maximum  plot 
magnitude  of  the  y-axis  to  150  resulting  in  Figure  4.5. 
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Figure  4.5  -  Zoomed  and  Normalized  Composite  Database 


Figure  4.5  shows  the  grouping  or  family  relationship  more  clearly  than 
Figure  4.4  does.  The  separate  families  of  categories  reflect  the 
stratification  of  the  data. 

If  the  data  were  separated  into  the  different  categories  and  plotted, 
estimators  could  easily  spot  the  multiple  stratifications.  But  what  if  all 
the  data  were  assumed  to  be  in  the  same  category?  If  this  were  true, 
estimators  might  be  inclined  to  see  a  single  exponential  relationship 
instead  of  multiple  ones,  especially  if  the  variance  (spread)  of  each 
category  was  larger.  Without  further  examination,  estimators  could 
calibrate  the  entire  set  of  data  and  produce  a  single  coefficient  and 
exponent  pair  for  a  single  model.  Calibration  of  the  entire  data  set  yielded 
a  coefficient  of  2.43  and  an  exponent  of  1.23.  Although  an  estimation 
model  with  these  parameters  might  not  account  for  each  of  the  separate 
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data  categories,  the  model  would  still  estimate  more  accurately  than  a 
model  that  was  not  calibrated  to  the  data  set.  Table  4.5  contains  the 
results  of  a  comparison  of  the  REVIC  embedded  mode  model  (a  =  3.312  & 
b  =  1.20)  and  a  model  using  the  calibrated  parameters. 

Table  4.5 

Statistical  Evaluation  of  Calibration  Source 


Parameter 

Source 

RRMS 

Avg 

MRE 

Predict 
Value  % 

% 

Improve 

REVIC 

0.7906 

1.176 

32.81 

12.0 

— 

Data  Calibration 

0.8072 

1.175 

28.54 

35.0 

68% 

The  results  in  Table  4.5  demonstrated  that  estimating  effort  from 
calibrated  models  could  be  more  accurate  than  estimating  from  a  model 
that  is  uncalibrated.  In  fact,  if  the  calibration  is  performed  properly  and 
the  calibration  data  adequately  represents  the  estimation  environment,  a 
calibrated  model  should  always  estimate  more  accurately  than  the  same 
uncalibrated  one.  Thus,  any  model  that  uses  statistical  correlation  can  be 
improved  by  calibration. 

By  dividing  the  data  into  functional  categories,  estimators  could 
obtain  more  accurate  coefficient/exponent  pairs.  For  example,  calibrating 
the  communication-identification  category  yielded  a  coefficient  of  1.37  and 
an  exponent  of  1.18  while  calibrating  the  offensive  sensor  category  yielded 
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a  coefficient  of  2.97  and  exponent  of  1.39*.  These  values  were  not  the 
same  as  those  for  the  entire  data  set.  Applying  each  of  the  evaluation 
measurements  from  Chapter  III  produced  the  results  printed  in  Table  4.6. 

Table  4.6 

Statistical  Evaluation  of  Categorical  Calibration 


Calibration 

Source 

R' 

RRMS 

Avg 

MRE 

Predict 
Value  % 

% 

Improve 

Entire 

Database 

Database 

0.8072 

1.175 

28.54 

35.0 

— 

Comm 

ID 

Database 

0.5236 

1.506 

26.86 

0.0 

— 

Category 

0.9763 

0.096 

100.0 

Nav 

Sensors 

Database 

0.9110 

0.351 

9.58 

75.0 

— 

Category 

0.9148 

0.113 

2.96 

90.0 

70.0 

Core 

Avionics 

Database 

0.9310 

0.257 

7.25 

70.0 

— 

Category 

0.9512 

0.15 

2.74 

90.0 

80.0 

Elect 

Combat 

Database 

0.6790 

1.748 

44.89 

25.0 

— 

Category 

0.7109 

1.630 

37.63 

50.0 

60.0 

Offensive 

Sensors 

Database 

0.6447 

0.740 

54.10 

5.0 

— 

Category 

0.9785 

0.137 

mm 

75.0 

95.0 

Table  4.6  revealed  the  potential  improvement  in  all  of  the 
measurements  by  calibrating  to  a  functional  data  set.  Categories  at  the 
edges  of  the  data  set,  such  as  communication-identification  and  offensive 
sensors,  did  show  a  pronounced  improvement  while  other  categories  in  the 
central  area  of  the  whole  data  set  did  not  show  as  much  improvement. 


These  values  are  not  the  same  as  the  input  parameters  because  of  the  effort  variability  introduced  when 
generating  the  data  points. 
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After  separating  the  categories,  graphing  the  families,  and 
evaluating  the  statistics,  it  was  an  easy  chore  to  determine  where  the 
improvements  were.  But  what  about  the  areas  where  there  were  no 
improvements?  Data  collection  data  for  analysis  required  much  effort,  so 
avoiding  data  collection  for  any  area  should  save  effort.  According  to  the 
graph  of  the  data  (Figure  4.5),  the  navigation  and  core  avionics  functions 
seemed  to  overlap  closely.  Comparing  the  navigation  and  core  avionics 
calibration  results  with  other  categories  in  Table  4.7  provided  some 
additional  clues. 


Table  4.7 

Category  Calibration  Results 


Category 

Coefficient 

Exponent 

Comm  /  ID 

1.3689 

1.1845 

Nav  Sensors 

2.4279 

1.1918 

Core  Avionics 

2.3197 

1.1923 

Elect  Combat 

1.7652 

1.3969 

Off  Sensors 

2.9665 

1.3876 

Entire  Database 

2.4291 

1.2278 

Table  4.7  confirmed  that  the  coefficients  and  exponents  of  the  navigation 
and  core  avionics  categories  were  close  to  each  other.  Therefore,  it  made 
sense  not  to  collect  data  for  these  two  categories  separately  but  to  combine 
them  into  one  group  with  a  single  calibration.  Calibrating  these  two 
categories  together  as  one  category  produced  a  coefficient  of  2.3925  and  an 
exponent  of  1.1898.  Neither  of  these  new  values  were  significantly 
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different  from  the  previous  values,  so  treating  both  categories  as  one  would 
not  greatly  affect  the  accuracy  of  any  predictions  for  block  changes  in  these 
categories.  Of  course,  this  prediction  assumed  that  the  future  behavior  of 
these  categories  would  follow  the  past  performance.  This  may  or  may  not 
be  true,  but  an  informed  guess  should  be  better  than  an  ignorant  one. 

Another  category  which  would  probably  benefit  little  from  special 
calibration  attention  was  electronic  combat.  Because  the  variability  of  this 
category  was  high,  the  category  was  naturally  difficult  to  estimate. 
Collecting  extra  data  to  enable  estimators  to  calibrate  a  new  parameter 
pair  would  probably  be  less  helpful  than  collecting  extra  data  on  a  more 
promising  category  such  as  communication-identification.  The  calibration 
from  the  entire  data  set  predicted  almost  as  well  as  the  functional 
calibration  for  the  electronic  combat  category. 

For  the  second  h5rpothesis  of  functional  calibration,  we  have 
demonstrated  the  main  benefit  of  producing  new  prediction  relationships 
based  upon  a  selected  subset  of  data.  The  subset  could  be  an  entire  group 
of  data  such  as  avionics  or  subset  families  of  a  group.  In  either  case,  the 
main  benefit  would  be  improved  prediction  accuracy.  The  generated 
database  separated  a  fictional  database  into  five  functional  categories. 

The  communication-identification  and  offensive  sensors  calibrations  offered 
the  most  promising  improvements  and  warranted  their  own  calibration 
curves.  On  the  other  hand,  the  navigation,  core  avionics,  and  electronic 
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combat  categories  demonstrated  less  potential  for  improved  accuracy  and 
might  be  better  treated  as  a  single  group. 

Hypothesis  1.  Functional  calibration  for  the  second  hypothesis  was 
not  the  only  way  to  demonstrate  prediction  accuracy  improvements.  By 
generating  data  that  fit  the  first  hypothesis,  construction  of  a  bottom-up 
cost  model,  we  demonstrated  another  possible  improvement.  Creating  a 
database  for  the  first  hypothesis  required  a  series  of  block  changes  for  a 
lifecycle.  Each  lifecycle  had  to  mirror  the  temporal  changes  suggested 
within  the  literature  review.  The  concept  of  generating  a  series  of  data 
points  was  similar  to  the  concept  used  to  create  a  single  data  point.  The 
prototype  determined  the  effort  for  a  particular  block  change  size  and  then 
added  some  random  deviation.  The  wrinkle  this  time  was  to  change  the 
support  effort  to  match  the  bath-tub  curve  espoused  in  the  literature. 
Recall  from  Chapter  II  the  four  temporal  effects  which  impacted  the 
size/effort  relationship  and  made  the  bath-tub  curve.  The  prototype 
modeled  the  memory  effect,  throughput  effect,  and  the  learning  effect  but 
discarded  the  entropy  effect  because  there  were  no  quantifiable 
relationships  for  entropy.  The  bath-tub  shaped  lifecycle  came  entirely 
from  the  first  three  temporal  effects. 

The  prototype  constructed  a  series  database  with  the  inputs  shown 
in  Table  4.8. 
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Table  4.8 


Input  Parameters  for  Series  Database 


Parameter 

Value  1 

Number  of  Block  Changes 

20 

Development  Size  in  KOSI 

100 

Development  Memory  UtiKzation  Percentage 

50.0 

Development  Throughput  Utilization  Percentage 

50.0 

Effort  Standard  Deviation 

2.0 

Adjustment  Factor  Standard  Deviation 

0.17 

Prediction 

Coefficient 

2.80 

Parameters 

Exponent 

1.20 

Percentages  of  Total  Size 
for  EDSI  calculation 

%  Added 

5.0 

%  Modified 

10.0 

%  Deleted 

2.0 

%  Standard  Deviation 

0.3 

We  selected  the  input  values  in  order  to  generate  a  data  set  that  could 
demonstrate  the  effects  discussed  in  the  literature  review.  The  resulting 


data  can  be  found  in  Appendix  F  and  in  Figure  4.6. 


Figure  4.6  -  Series  Block  Change  Database 


4.36 


The  most  noteworthy  characteristic  of  this  data  was  the  initial  decrease  in 
effort  during  the  first  six  block  changes  followed  by  an  increase  in  effort 
towards. the  later  block  changes.  By  normalizing  the  data  to  remove  the 
variation  induced  by  changing  adjustment  factors,  the  prototype  more 
clearly  displayed  the  temporal  effects  in  Figure  4.7. 
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Figure  4.7  •  Normalized  Series  Block  Change  Database 


Figure  4.7  demonstrated  what  happened  to  avionics  support  effort  as  the 
learning  effect  died  out  and  was  overtaken  by  the  effects  of  depleting  the 
remaining  throughput  and  memory.  The  effort  for  the  last  block  change 
was  more  than  double  the  effort  from  the  first  block  change.  If  the 
temporal  effects  were  accurately  modeled,  then  it  was  easy  to  understand 
why  models  which  don't  include  these  effects  could  be  less  accurate.  A 
model  that  simply  assumed  a  constant  level  of  effort  could  not  account  for 
learning  or  any  effect  of  growth. 
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Although  the  data  in  Figure  4.6  does  not  deplete  all  of  the 
remaining  memory  or  throughput,  a  data  set  which  did  approach  the  100% 
limits  demonstrated  the  value  of  controlling  growth.  By  adjusting  the 
percent  added  code  from  5%  to  6%  and  holding  the  other  inputs  constant, 
the  prototype  demonstrated  the  growth  effects  as  graphed  in  Figure  4.7. 


Figure  4.8  -  Support  Data  at  6%  Added  Code 


The  effort  leveling  during  the  last  three  block  changes  demonstrated  the 
effect  of  memory  and  throughput  utilization  approaching  100%.  Operating 
in  this  area  is  very  costly.  Figure  4.9  displays  the  memory  utilization  for 
separate  examination. 


Figure  4.9  -  Memory  Utilization  Growth 


The  memory  utilization  grew  steadily  until  reaching  about  95%  where  it 
began  to  taper.  The  throughput  utilization  exhibited  a  similar  growth 
pattern.  Although  the  consumption  of  these  two  resources  significantly 
altered  the  later  portions  of  this  support  lifecycle,  the  high  effort  was 
partially  offset  by  the  learning  which  occurred  during  the  early  portion  of 
the  lifecycle.  Figure  4.10  displayed  the  values  for  the  language  experience 
(LEXP)  adjustment  factors  as  altered  by  the  learning  effect. 


Figure  4.10  -  Learning  Effect  for  Language  Experience 

The  learning  effect  was  manifested  only  during  the  first  six  block  changes, 
and  after  that  point,  it  did  not  help  reduce  the  require  effort.  Since  all 
three  temporal  effects  influenced  effort  by  altering  adjustment  factors,  it 
was  worthwhile  to  examine  the  total  contribution  of  the  temporal  effects 
by  graphing  the  adjustment  factor  products  (O)  for  successive  block 
changes.  The  products  are  graphed  in  Figure  4.11. 
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Figure  4.11  -  Block  Change  Adjustment  Products 

The  shape  of  Figure  4. 1 1  was  the  same  shape  of  a  graph  of  normalized 
efforts.  This  match  was  not  surprising  since  the  change  in  support  effort 
came  entirely  through  the  change  in  adjustment  factors. 

After  reviewing  the  results  of  the  software,  we  concluded  the 
prototjrpe  model  was  an  excellent  tool  to  demonstrate  the  hypotheses. 
Although  actual  data  would  have  enabled  the  software  to  validate  or 
disprove  the  relationships,  the  prototype  demonstrated  a  way  and  provided 
a  tool  for  future  researchers  to  make  these  conclusions. 

KEVICynxitotype  Model  Conqjarison 

Despite  the  utility  of  the  prototype  in  demonstrating  the  hypotheses, 
we  also  compared  the  order  of  magnitudes  of  the  effort  predictions  from 
the  model  against  well-established  models.  Since  the  prototype  and 
REVIC  models  are  both  adaptations  of  the  COCOMO  model,  it  made  sense 
to  compare  the  outputs  from  the  REVIC  model,  the  COCOMO  model  and 
the  prototype  model.  The  comparison  expanded  to  include  the  SASET  and 
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SEER  models  because  those  models  were  readily  available.  The 
comparison  was  simplified  by  constraining  all  the  adjustment  factors  in 
the  COCOMO-based  modela  to  nominal  values  (1.0).  The  inputs  of  the 
other  models  were  also  nominalized  to  the  extent  possible.  Nominalizing 
the  model  permitted  comparing  of  the  results  and  avoided  accounting  for 


model-specific  differences.  Nominalization  also  reduced  each  of  the 
COCOMO-based  models  to  forms  similar  to  the  basic  COCOMO  model 
presented  in  Chapter  II.  The  comparison  results  are  shown  in  Table  4.9. 


Table  4.9 


Support  Model  Comparisons 


REVIC 

COCOMO 

SASET 

SEER 

Proto 

Proto 

Block 

Changes 

15 

15 

15 

15 

15 

15 

Oevel 

HOI 

100 

100 

100 

100 

100 

Inputs 

Size 

KDSI 

KDSI 

KDSI 

KDSI 

KDSI 

Block 

10% 

10% 

10% 

0%  add 

6%  add 

Change 

ACT 

ACT 

ACT 

20%  md 

12%  md 

Size 

■m 

0%  del 

2%  del 

Outputs 

Effort 

1 

(MM) 

124.8 

83.19 

63.72 

393.84 

84.9 

84.9 

2 

108.2 

83.19 

54.12 

243.36 

65.4 

68.6 

3 

95.7 

46.2 

167.78 

56.2 

61.8 

4 

83.2 

37.56 

167.78 

50.5 

58.1 

5 

31.44 

46.4 

56.0 

6 

28.8 

43.3 

54.9 

7 

26.16 

43.3 

57.5 

8 

22.68 

67.9 

13 

8.76 

146.7 

14 

6.12 

171.1 

15 

83.2 

83.19 

3.48 

167.78 

43.3 

199.6 
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The  comparison  results  printed  in  Table  4.9  indicated  that  the  prototype 
model  predicted  efforts  that  were  neither  the  highest  nor  the  lowest  of  the 
well-established  models.  Thus,  the  prototype  generated  effort  values 
within  an  order  of  magnitude  of  the  other  models. 

Condusion 

Although  we  would  have  preferred  using  actual  data,  we 
accomplished  all  of  the  objectives  using  generated  data.  Demonstration  of 
Hypothesis  1  began  by  modeling  the  current  block  change  process  using 
object  oriented  design  techniques.  The  block  change  process  model  and  the 
literature  review  provided  the  foundations  for  creating  a  software 
computer  model.  The  prototype  demonstrated  the  improved  accuracy  of  a 
bath-tub  shaped  series  of  block  changes  and  an  order  of  magnitude 
accuracy  compared  to  COCOMO,  REVIC,  SASET,  and  SEER.  These 
actions  satisfied  the  first  three  objectives  for  Hypothesis  1  as  stated  in 
Chapter  I. 

We  also  achieved  the  first  objective  for  H3q)othesis  2  as  stated  in 
Chapter  I.  The  protot)T)e  demonstrated  the  improved  accuracy  of 
functionally  calibrating  software  support  estimation  models.  The 
remaining  objectives  for  both  hypotheses  are  recommendations  that  are 
covered  in  the  next  chapter. 

Lack  of  data  was  an  unfortseen  obstacle  that  we  overcame  with  the 
prototype  by  generating  fictional  data.  Actual  data  existed  but  not  in  a 
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readily  accessible  form.  The  lack  of  data  forced  a  deviation  from  the 
original  concept  of  validating  the  model  to  demonstrating  the  prototype. 
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V,  Conclusions  &  Recommendations 


Chapto*  Overview 

In  this  chapter,  we  present  conclusions  that  were  supported  by  our 
research.  Also  presented  are  recommendations  for  improving  software 
support  estimation.  The  conclusions  and  recommendations  are  grouped 
according  to  the  topics  of  data;  Hypothesis  1  (functional  model 
development),  H)rpothesis  2  (functional  calibration),  and  the  model 
comparison  methodology.  The  chapter  concludes  by  identifying  other 
topics  for  additional  research. 

Data 

Condusions.  We  were  unable  to  find  sufficient  data  through  direct 
collection  and  through  literature  research  to  confirm  or  refute  the 
hypotheses.  However,  our  efforts  supported  two  conclusions.  The  first 
conclusion  was  that  the  efficiency  of  an  SSA  will  not  remain  constant  over 
the  PDSS  lifecycle  for  aircraft  avionics  software.  The  second  conclusion 
was  that  a  software  support  database  needs  to  be  constructed  to  help 
study  long-term  SSA  efficiency.  Each  conclusion  is  discussed  below. 

The  nature  of  the  software  support  process  coupled  with  the 
constraints  imposed  by  a  target  computer  suggested  that  a  bath-tub 
shaped  curve  existed  which  was  not  captured  in  REVIC,  SEER,  or  SASET 
maintenance  models.  However,  the  literature  confirmed  the  existence  of 
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this  curve.  There  were  four  factors  that  affected  the  shape  of  this  curve. 
The  first  was  a  learning  effect  acquired  through  exposure  to  the  software. 
The  second  was  simple  size  growth  during  the  PDSS  cycle.  The  third  was 
the  loss  of  available  memory  and  throughput  as  size  increased.  The  fourth 
was  design  entropy  caused  by  repeated  changes  to  the  software.  Further 
research  into  each  of  these  factors  could  lead  to  understanding  the 
temporal  effects  and  to  identifying  any  interdependencies. 

The  second  conclusion  was  the  need  for  a  support  database  to 
quantify  the  four  temporal  effects.  A  database  is  a  prerequisite  to  support 
model  development  and  PDSS  estimation  improvements.  The  data 
uncovered  during  the  research  was  insufficient  to  validate  the  hypotheses 
and  forced  the  generation  of  sample  data.  Until  sufficient  data  is  collected 
for  analysis,  no  further  progress  can  be  made  on  either  hypothesis,  nor  can 
an  evaluation  of  the  existing  models  be  accomplished.  The  specific 
attributes  of  the  database  are  discussed  in  the  next  section. 

Reocmmendations.  Building  an  adequate  support  database  will  be  a 
challenge.  The  database  must  have  time  series  information  on  a  sufficient 
number  of  software  projects  to  allow  the  revision  and  calibration  of  present 
models  to  a  support  environment.  The  database  must  also  contain  high 
quality  information  and  requires  a  well-defined  data  collection  plan  that 
must  be  strictly  followed.  Each  database  element  must  be  precisely 
defined  to  reduce  confusion  during  collection  and  interpretation.  Besides 
these  general  characteristics,  we  made  specific  recommendations  about 
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collecting  size  and  adjustment  factors.  Size,  the  most  important 
parameter,  will  be  discussed  first. 

Good  size  data  is  the  cornerstone  for  a  good  PDSS  database.  As 
mentioned  in  Chapter  11,  all  the  other  factors  simply  adjusted  the  effort 
estimate  obtained  from  size.  Support  size  was  similar  to  development  size, 
but  there  were  some  key  differences.  Both  support  and  development  size 

required  a  standard  definition.  It  is  not  sufficient  to  simply  ask  for  size  in 

« 

SLOG,  KDSI,  function  points,  or  any  other  size  units  without  a  standard 
definition  of  the  metric.  Implied  in  this  statement  is  a  software  language 
dependency;  the  definition  of  size  is  likely  to  be  highly  language 
dependent.  However,  the  goal  is  to  define  the  metric  so  that  two  different 
estimators  will  generate  the  same  size  count  for  a  given  piece  of  software. 
One  solution  would  be  to  embed  the  sizing  rules  into  a  software  tool  and  to 
use  it  on  each  support  tape  entered  into  a  PDSS  database.  This  would 
provide  an  accurate  starting  size  for  each  block  change.  Now  given  the 
starting  size  of  a  baseline,  estimators  could  calculate  the  effort  per  EDSI 
observed  in  the  block  change.  At  this  point,  the  recommendations  diverge 
from  sizing  techniques  common  to  development. 

Support  software  size  has  an  additional  measurement,  the  size  of 
the  changed  code,  that  development  size  does  not  have.  Software  support 
estimates  should  derive  effort  from  the  size  of  the  changed  code  as  well  as 
the  total  code  size.  A  consistent  way  to  measure  the  change  size  would  be 
to  compare  a  baseline  tape  with  a  tape  produced  after  a  block  change 
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cycle.  All  of  the  code  that  was  added,  deleted,  or  modified  must  be 
counted.  Again,  the  counting  metrics  must  be  defined  clearly  so  they  can 
be  applied  uniformly.  Of  all  the  possible  size  measures,  SLOG  (or  KDSI)  is 
a  measure  that  is  usually  familiar  to  software  engineers  since  they  usually 
work  with  lines  of  code  (or  source  instructions).  Therefore,  we  recommend 
that  a  set  of  language-specific  definitions  for  added,  deleted,  and  modified 
SLOG  be  created  and  codified  into  a  standard  software  tool  for  measuring 
the  size  of  baseline  code  and  for  measuring  changes  to  the  code.  Only  size 
measured  by  the  standard  tool  should  be  aUowed  into  the  PDSS  database. 

Along  with  size  data,  adjustment  factors  need  to  be  gathered  to 
account  for  other  variables  present  in  the  block  change.  Until  a  better 
support  model  is  available,  we  do  not  recommend  a  standard  set  of 
adjustment  factors  for  data  collection.  In  the  mean  time,  collecting  all  of 
the  support  adjustment  factors  from  the  Air  Force  recommended  models 
(REVIG,  SASET,  SEER,  and  PRIGE-S)  should  suffice.  We  made  no 
conclusion  which  models  or  attributes  to  drop  from  the  PDSS  database. 
However,  three  critical  areas  should  be  included  in  any  database.  As  with 
size,  each  of  these  areas  needs  a  defined  metric  to  ensure  data  consistency. 
The  first  critical  area  is  the  experience  of  the  analysis,  design,  and  coding 
team.  The  team  size  and  average  experience  in  months  at  the  start  of  the 
block  change  cycle  should  be  part  of  the  PDSS  database.  This  information 
is  needed  to  study  the  learning  effect. 


5.4 


The  second  critical  area  is  the  remaining  memory  and  throughput. 
Although  measuring  these  attributes  can  be  complex  and  highly  machine 
dependent,  the  important  characteristic  to  capture  is  the  designer's 
perception  of  remaining  memory  and  throughput.  It  is  equally  vital  to 
record  any  hardware  changes  that  increase  available  memory  and 
throughput.  Expressing  the  available  memory  and  throughput  as  a 
percentage  is  reasonable  given  the  complexity  of  the  measurements. 

Even  more  complex  to  measure  than  remaining  memory  and 
throughput  is  the  third  critical  area,  design  entropy.  Although  all  the 
factors  that  contribute  to  design  entropy  unknown,  one  cure  for  design 
entropy  is  to  re-engineer  the  software  (Sittenauer:7-10).  Another  less 
drastic  cure  is  to  restructure  the  software  (Corbi:294-306).  Unfortunately, 
no  single  metric  existed  that  captured  all  of  the  software  attributes  that 
restructuring  and  re-engineering  restore.  But  there  are  many  metrics  that 
can  capture  a  subset  of  those  attributes  (Oman:337-344,  Fenton:  150-259). 
The  question  is  which  metrics  capture  design  entropy  with  reasonable  data 
collection.  We  recommend  that  the  PDSS  database  retain  the  baseline 
code  and  documentation  for  each  block  change.  We  also  recommend 
further  investigation  into  the  nature  and  measurement  of  design  entropy 
to  define  a  set  of  metrics  for  inclusion  in  a  PDSS  database. 

A  PDSS  database  is  not  the  only  method  of  researching  maintenance 
productivity  over  time.  Further  literature  research  into  the  learning 
curve,  memory/throughput  effects,  and  design  entropy  effects  may  prove 
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&\utful.  There  may  be  other  factors  not  identified  in  this  thesis  that 
contribute  to  the  bath-tub  temporal  effects. 

Hypothesis  1:  Functional  Construction  of  a  Software  Estimation  Model 
Condusions.  Describing  the  block  change  process  using  software 
design  tools  provided  excellent  results.  The  object  model  labeled  the 
agents  involved  in  the  PDSS  environment  while  the  functional  model 
described  the  subprocesses  within  the  block  change  process.  The  graphic 
nature  of  our  object  model  allowed  quick  assignment  of  the  COCOMO 
effort  adjustment  factors  to  specific  agents  in  the  PDSS  environment, 
while  the  graphic  mt’  re  of  the  functional  model  allowed  rapid 
identification  anu  resolution  of  differences  between  block  change  process 
descriptions.  The  result  was  a  product  that  was  traceable  to  MIL-HDBK- 
347  and  to  previous  work  done  by  Sacramento  ALC.  The  next  task  was  to 
functionally  construct  a  software  estimation  model  based  on  the  block 
change  process  described  by  the  process  model. 

The  concept  of  a  functionally  constructed  software  estimation 
model,  given  a  functional  description  of  the  process,  is  to  estimate  each 
function  (subprocess)  individually  and  then  sum  the  total.  Once  the  block 
change  process  was  correctly  depicted,  the  subprocesses  best  represented 
by  the  COCOMO  maintenance  model  were  included  in  the  prototype 
software.  The  prototype  included  only  the  "develop  changes"  subprocess 
because  there  was  insufficient  data  to  include  other  subprocesses. 
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Estimators  in  the  field  should  included  their  own  selection  of  subprocesses 
based  on  the  data  available  for  calibration  and  for  other  estimation 
methods  (analogy  or  bottom-up).  Having  identified  what  part  of  the  block 
change  process  the  prototype  would  address,  we  next  manipulated  the 
COCOMO  adjustment  factors  to  mirror  the  bath-tub  curve  supported  by 
literature. 

The  software  prototype  successfully  created  a  bath-tub  curve  over  a 
series  of  block  changes.  The  fidelity  and  accuracy  of  the  prototype 
compared  to  an  actual  series  of  block  changes  was  unknown.  With  no 
usable  data  to  test  against  the  prototype,  we  could  only  assert  that  the 
prototype  represented  the  temporal  effects  of  software  support  better  than 
the  ACT  based  models  of  REVIC,  SASET,  and  SEER  did. 

Reoommendations.  We  have  two  recommendations  regarding  the 
prototype  model.  The  first  is  to  validate  and  calibrate  it  with  quality  data 
as  soon  as  possible.  This  is  necessary  to  both  confirm  the  existence  of  the 
bath-tub  curve.  Once  the  prototype  is  validated  and  calibrated,  the  second 
recommendation  is  to  prompt  model  designers  to  update  the  existing 
support  process  models  to  incorporate  a  bath-tub  curve. 

Hypothesis  2:  Functional  Calibration  to  In^nove  Model  Accuracy 

Conclusions.  Calibration  of  support  (or  development)  estimation 
models  is  essential.  The  closer  the  calibration  data  matches  the  expected 
system,  the  closer  the  estimate  should  be.  The  importance  of  proper 
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calibration  is  under  emphasized.  Unfortunately,  calibration  for  support 
models  is  not  as  simple  as  calibration  for  development  models. 

Support  model  calibration  models  is  feasible  and  can  take  two  forms, 
horizontal  and  vertical.  Each  form  takes  a  different  temporal  slice  of  the 
PDSS  lifecycle.  Horizontal  calibration  captures  all  of  the  long-term,  stable 
characteristics  of  a  PDSS  lifecycle.  This  is  critical  for  estimators  to 
understand  and  is  the  key  to  identifying  unique  adjustment  factors  for  an 
SSA.  Long-term  calibration  may  alleviate  the  need  for  some  of  the 
adjustment  factors.  Models  do  not  need  variables  that  account  for 
attributes  which  remain  constant  over  the  long-term.  Vertical  calibration 
is  similar  to  developmental  calibration.  Each  uses  the  i***  development 
cycle  from  a  number  of  systems  to  capture  those  processes  common  across 
those  systems  for  that  particular  cycle. 

Reocmmendations.  The  hrst  recommendation  to  include  ease  of 
calibration  as  a  criterion  to  judge  estimation  models.  A  model  that  cannot 
be  easily  calibrated  loses  much  of  its  utility.  If  a  model  can't  be  easily 
calibrated,  then  the  estimator  must  know  what  data  was  used  to  calibrate 
the  model  originally  and  realize  that  estimating  effort  outside  of  this  data 
domain  is  likely  to  be  inaccurate. 

The  second  recommendation  is  to  use  models  that  can  be  calibrated 
in  a  repeatable  manner.  One  test  of  model  calibration  is  to  use  the 
calibration  procedure  with  the  original  data  to  see  if  it  is  repeatable.  If 
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the  recalibrated  model  doesn't  match  the  original,  then  there  is  a  serious 
problem  that  needs  resolution  before  using  the  model. 

The  third  recommendation  is  to  avoid  using  a  model  without 
understanding  how  it  was  calibrated  and  with  what  data.  This 
information  is  vital  to  understanding  what  bias  might  exist  in  an  estimate. 
This  is  a  serious  problem  with  proprietary  models  with  no  simple 
solutions.  However,  a  quality  Air  Force  database  can  help  solve  this 
problem.  Given  a  quality  database,  we  recommend  calibration  of  a  model 
to  that  database  prior  to  estimating,  especially  if  the  model's  calibration 
database  is  unknown  to  the  estimator. 

Our  fourth  recommendation  is  to  train  estimators.  Estimators  need 
to  be  trained  how  to  calibrate  the  models,  especially  if  the  models  use  a 
complex  calibration  procedure.  Again,  a  readily  available  database  is 
needed  before  training  in  model  or  else  calibration  will  be  ineffective. 
Additional  training  on  the  nature  of  software,  software  metrics,  and  the 
processes  used  to  create  software  should  help  estimators  create  better 
estimates.  If  nothing  else,  the  training  will  help  software  engineers  and 
estimators  communicate  better  to  improve  estimation. 

The  final  recommendation  centers  is  to  exploit  the  PDSS  database 
when  it  becomes  available.  Long-term  data  from  a  PDSS  database  will 
highlight  factors  that  are  best  captured  under  calibration.  Using  analysis 
of  variance  (ANOVA)  techniques  on  all  the  factors  should  reveal  those 
adjustment  factors  that  are  sufficiently  stable  over  time  to  be  firmly 
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captured  in  calibration.  This  calibration  should  reduce  the  number  of 
variable  factors  that  need  to  be  maintained  in  the  database. 

Future  Besearch  Tc^cs 

The  single  most  important  research  topic  is  block  change  size 
estimation.  Size  is  the  driver  of  all  the  Air  Force  recommended  models. 
Further  research  could  determine  the  proper  weighting  for  changed  lines, 
added  lines,  and  deleted  lines  to  produce  a  support  size  with  the  highest 
correlation  to  support  effort.  Researchers  also  need  to  investigate  better 
methods  of  size  estimation  in  preparation  for  a  block  change  since  block 
change  efforts  do  not  come  from  measured  EDSI  inputs  but  from  estimate 
EDSI  inputs.  Better  effort  estimates  require  adequate  models  and  quality 
size  estimates. 

Summary 

While  software  support  estimation  is  a  fertile  field  for  future 
research,  the  key  to  future  research  is  in  creating  a  support  database. 
Once  a  large  enough  database  is  gathered,  the  current  generation  of 
software  support  models  can  be  calibrated  and  validated  to  specific 
environments.  Estimators  can  make  further  improvements  to  the  current 
estimation  models  for  avionics  software  support  by  incorporating  temporal 
effects  such  as  learning,  size  growth,  memory/throughput  growth,  and 
design  entropy. 
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In  this  thesis,  we  reviewed  the  current  literature  dealing  with 
software  cost  estimation  models  and  the  software  support  environment. 

We  also  presented  methodologies  to  document  the  support  process  and  to 
compare  software  cost  estimation  models.  Furthermore,  we  created  a 
software  prototype  that  embodied  the  PDSS  lifecycle  as  described  in  the 
literature.  The  prototype  generated  data  to  demonstrate  how  current 
software  cost  estimation  models  could  be  improved  from  two  functional 
points  of  view,  functional  bottom-up  model  design  and  functional  top-down 
model  calibration.  We  demonstrated  that  both  techniques  can  improve 
cost  estimation  accuracy  and  provided  recommendations  for  data  collection, 
model  improvement,  and  future  research. 
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Appendix  A 

Object  Oriented  Model  Notation  Summary 
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Figure  A.  1  -  Object  Model  Notation 
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Figure  A.2  •  Functional  Model  Notation 
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Appendix  C 
Prototype  Source  Code 
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Source  Code  for  Prototype  in  Visual  Basic  Language. 


Code  for  Global. bas 

■Enuaerated  Database  type 
Global  Const  UnknoNrOB  *  0 
Global  Const  BoehaOB  >  1 
Global  Const  SaapleOB  ^  2 
Global  Const  ThesIsOB  >  3 
Global  Const  CoapThesisOB  «  4 

■Set  up  Enuaeraated  Values  for  YOata 

■Only  the  thesis  graph  needs  to  use  this 

Global  YPick  As  Integer 

Global  Const  Executable_Tiiae  *  1 

Global  Const  TimeJJtil  =  2 

Global  Const  Storage  s  3 

Global  Const  Meffl_Util  =  4 

Global  Const  Pi_Hult  >  S 

Global  Const  Analyst_Experience  <  6 

Global  Const  Lang_Ex^rience  >  7 

Global  Const  Actual  KDSl  ^  s 

Global  Const  EquivaTent_OSI  »  9 

Global  Const  Actual_Effort  >  10 

Global  Const  FileGraph  a  o 

■Global  Variables  for  Graph  Axis  Limits  and  Normalization  Flag 

■Should  only  be  used  by  forms  involved  with  graphing 

■(I  couldm^t  figure  another  way  to  pass  these  paraamters . ) 

Global  YHax  As  Single 
Global  YMin  As  Single 
Global  XNax  As  Single 
Global  XNin  As  Single 
Global  NormState  As  Integer 
Global  Const  Norm_0n  >  1 
Global  Const  NormJIff  *  0 

■Provide  Global  Variable  to  hold  current  open  database  filenaaie 
■and  Handle.  Permits  different  aienu  items  to  use  same  database. 

Global  DBFileSpec  As  String 
Global  OBFileName  As  String 
Global  OBHandle  As  Integer 

Global  more  As  Integer  ■flag  stating  if  more  records  exist 

Global  OBType  As  Integer  ■Enumerated  Database  Type 

Global  ErrNsg  As  String  ■string  for  error  mesaages 

■Define  Boehm^s  record  structure  from  database 
Type  BoehfflType 

Num  As  Variant  ■variant  type  permits  testing  of  null  values 

Type  As  Variant 

YEAR  As  Variant 

LANGUAGE  As  Variant 

RELY  As  Variant 

DBSIZE  As  Variant 

CPLX  As  Variant 

EXTIHE  As  Variant 

STOR  As  Variant 

VIRT  As  Variant 

TURN  As  Variant 

ACAP  As  Variant 

AEXP  As  Variant 

PCAP  As  Variant 

VEXP  As  Variant 

LEXP  As  Variant 

HOOP  As  Variant 

TOOL  As  Variant 

SCED  As  Variant 

RVOL  As  Variant 

Pi  As  Variant 

NODE  As  Variant 

TOTKDSI  As  Variant 
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AOJKOSI  As  Variant 

MOMEFFORT  As  Variant 

ESTEFFORT  As  Variant 

ACTEFFORT  As  Variant 

End  Type 

Global  BoehnRec  As  BoehmType 
Global  BoetusHandle  As  Integer 

Global  Const  BoehsADS  >  »(PROJ  NiJM(V)  PROJ  TypE(V)  YEAR(V)  LANGUAGE(V)  RELY(V)  DBSIZE(V)  CPLXIV) 
EXTIME(V)  STOR(V)  VIRT(V)  TURN(V)  ACAP(V)  AEXP(V)  PCAP(V)  VEXP(V)  LEXP(V)  NGOP(V)  TOOL(V)  SCEO(V) 
RVOL(V)  Pi(V)  NOOEIV)  TOTKOSKV)  AOJKOSI (V)  NONEFFORT(V>  ESTEFFORT(V)  ACTEFFORTIV)}" 


■Define  Short  version  of  Beohsi's  type  for  creating  saaple  databases 
Type  SampleType 


Hua 
Type 
RELY 
0BSI2E 
CPLX 
EXTIME 
STOR 
VIRT 
TURN 
ACAP 
AEXP 
PCAP 
VEXP 
LEXP 
NOOP 
TOOL 
SCED 
RVOL 
Pi 

ACTKOSI 
ACTEFFORT 


As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 
As  Variant 


■variant  type  peraiits  testing  of  null  values 


End  Type 

Global  SatnpleRec  As  SainpleType 
Global  SanpleHandle  As  Integer 

Global  Const  SanpleROS  3  ■■(PROJ  NUM(V)  PROJ  TYPE(V)  RELY(V)  DBSIZE(V)  CPLX(V)  EXTIME(V)  STOR(V) 
VIRT<V)  TURN(V)  ACAP(V)  AEXP(V)“PCAP<V)  VEXP<V)  LEXP(V)  MOOPIV'  TOOL(V)  SCEO(V)  RVOL(V)  PUV) 
ACTKOSI <V)  ACTEFFORTIV))^' 


■Define  Thesis  record  Structure 
Type  ThesisType 


BCNUM 

As 

Variant 

CATEGORY 

As 

Variant 

RELY 

As 

Variant 

DBSIZE 

As 

Variant 

CPLX 

As 

Variant 

TIMEUTIL 

As 

Variant 

EXTIME 

As 

Variant 

MEMUTIL 

As 

Variant 

STOR 

As 

Variant 

VIRT 

As 

Variant 

TURN 

As 

Variant 

ACAP 

As 

Variant 

AEXP 

As 

Variant 

PCAP 

As 

Variant 

VEXP 

As 

Variant 

LEXP 

As 

Variant 

NOOP 

As 

Variant 

TOOL 

As 

Variant 

SCED 

As 

Variant 

RVOL 

As 

Variant 

Pi 

As 

Variant 

ENTROPY 

As 

Variant 

ACTKOSI 

As 

Variant 

AODKDSI 

As 

Variant 

MOOKOSI 

As 

Variant 

DELKDSI 

As 

Variant 

EDS  I 

As 

Variant 

ACTEFFORT 

As 

Variant 

End  Type 

Global  ThesisRec  As  ThesisType 
Global  ThesisHandle  As  Integer 


■variant  type  permits  testing  of  null  values 
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Global  Const  ThesisROS  >  »<BCNUM<V)  CATEGORYCV)  RELYIV)  DBSIZE(V)  CPLX(V)  TIMEUTIL(V)  EXTINE(V) 
MEMUTUCV)  STOR(V)  VIRT(V)  TURN(V)  ACAP(V)  AEXP(V)  PCAP<V)  VEXP(V)  LEXP(V)  NOOP(V)  TO(».(V)  SCED(V) 
RVOL(V)  PI(V)  ENTROPY(V)  ACTKOSKV)  AOOKDSKV)  HOOKOSKV)  DELKOSUV)  EOSI(V)  ACTEFFORKV)}** 

'Oefina  BadThesis  record  Structure 
Type  OldThesisType 
BCNUM  As  Var 

CATEGORY  As  Var 

RELY  As  Var 

OBSIZE  As  Var 

CPLX  As  Var 

TIHEUTIL  As  Var 

EXTIME  As  Var 

MEMUTIL  As  Var 

STOR  As  Var 

VI RT  As  Var 

TURN  As  Var 

ACAP  As  Var 

AEXP  As  Var 

PCAP  As  Var 

VEXP  As  Var 

LEXP  As  Var 

MOOP  As  Var 

TOOL  As  Var 

SCED  As  Var 

RVOL  As  Var 

Pi  As  Var 

ENTROPY  As  Var 

ACTKOSI  As  Var 

AOOKOSI  As  Var 

MOOKDSI  As  Var 

OELKOSI  As  Var 

ESDI  As  Var 

ACTEFFORT  As  Var 

End  Type 

Global  OldThesisRec  As  OldThesisType 
Global  OldThesisHandle  As  Integer 

Global  Const  OldThesisROS  =  "CBCNUM(V)  CATEGORYIV)  RELY(V)  DBSIZE(V)  CPLX(V)  TIMEUTIL(V)  EXTINE(V) 
MEMUTILIV)  STOR(V)  VIRT(V)  rURN(V)  ACAP(V)  A£XP(V)  PCAP{V)  VEXP(V>  LEXP{V)  MOOP{V)  TOOL(V)  SCED(V) 
RVOL(V)  PI(V}  ENTROPY(V)  ACTKOSI  (V)  AOOKDSKV)  HOOKOSKV)  DELKDSKV)  ESOKV)  ACTEFFORT(V)}« 

1 1 1 1 1 1  ( 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

'  Visual  Basic  global  constant  file.  This  file  can  be  loaded 
’  into  a  code  module. 

I 

'  Some  constants  are  commented  out  because  they  have 
'  duplicates  (e.g.,  NONE  appears  several  places). 

t 

'  If  you  are  updating  a  Visual  Basic  1.0  program  to  run  in 
'  Visual  Basic  2.0,  you  should  replace  your  global  constants 
'  with  the  constants  in  this  file.  Note  that  True  and  False 
'  are  now  built  into  Visual  Basic  so  are  no  longer  defined  in 
'  this  file. 

I 

IIIIIIIIIIIIIIIIIIIMIIIIIII 


'  General 

'  Clipboard  formats 
Global  Const  CF  LINK  =  &HBF00 

Global  Const  CF“TEXT  =  1 

Global  Const  CF~BITMAP  =  2 
Global  Const  CF>ETAFILE  =  3 
Global  Const  CF~DIB  a  8 
Global  Const  CF>ALETTE  =  9 

'  DragOver 

Global  Const  ENTER  =  0 

Global  Const  LEAVE  =  1 

Global  Const  OVER  -  2 

'  Drag  (controls) 

Global  Const  CANCEL  =  0 
Global  Const  BEGIN  DRAG  =  1 


ant  'variant  type  permits  testing  of  null  values 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 

ant 
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Global  Const  END_0RAG  ^  2 

'  Show  parameters 
Global  Const  MODAL  >  1 
Global  Const  MODELESS  >  0 

'  Arrange  Method 
'  for  MDI  Forms 
Global  Const  CASCADE  >  0 
Global  Const  TILE  HORIZONTAL  =  1 
Global  Const  TILE~VERTICAL  =  2 
Global  Const  ARRANGE.ICONS  =  3 

■ZOrder  Method 

Global  Const  BRINGTOFRONT  >  0 
Global  Const  SENDTOBACK  -  1 

'  Key  Codes 

Global  Const  KEY  LBUTTON  =  &H1 
Global  Const  KEY~RBUTTON  =  &H2 
Global  Const  KEY~CANCEL  *  &H3 

Global  Const  KEY~MBUTTON  =  &H4  ‘  NOT  contiguous  with  L  & 

Global  Const  KEY  BACK  =  &H8 

Global  Const  KEY  TAB  =  &H9 

Global  Const  KEY~CLEAR  >  &HC 

Global  Const  KEY~RETURN  =  &H0 

Global  Const  KEY~SHIFT  ^  &H10 

Global  Const  KEY~CONTROL  =  &H11 

Global  Const  KEY~MENU  =  &H12 

Global  Const  KEY~PAUSE  >  ftH13 

Global  Const  KEY~CAPITAL  <  &HU 

Global  Const  KEY~ESCAPE  =  &H1B 

Global  Const  KEY~SPACE  »  &h20 

Global  Const  KEY'PRIOR  =  &H21 

Global  Const  KEY~NEXT  ^  £H22 

Global  Const  KEY~END  =  ftH23 

Global  Const  KEY"homE  =  &H24 

Global  Const  KEY“LEFT  *  &H25 

Global  Const  KEY'UP  *  iH26 

Globul  Const  KEY'RIGHT  »  &H27 

Global  Const  KEY~DOUN  -  &H28 

Global  Const  KEY~SELECT  =  SH29 

Global  Const  KEY~PR1NT  ^  &H2A 

Global  Const  KEY~EXECUTE  =  &H2B 

Global  Const  KEY~SNAPSHOT  »  &H2C 

Global  Const  KEY“insERT  =  &H2D 

Global  Const  KEY“dELETE  =  &H2E 

Global  Const  KEY_HELP  =  &H2F 

'  KEY  A  thru  KEY  Z  are  the  same  as  their  ASCII  equivalents: 
'  KEY”0  thru  KEY“9  are  the  same  as  their  ASCII  equivalents: 

Global  Const  KEY  NUMPAOO  =  &H60 
Global  Const  KEY~NLINPA01  =  &H61 
Global  Const  KEY~NUHPA02  =  &H62 
Global  Const  KEY~NUMPAD3  -  &H63 
Global  Const  KEY~NUMPAD4  =  &H64 
Global  Const  KEY~NUHPA05  =  8H65 
Global  Const  KEY~NUMPA06  =  &H66 
Global  Const  KEY~NUMPAD7  =  &H67 
Global  Const  KEY~NUMPA08  =  &H68 
Global  Const  KEY“numPA09  =  SH69 
Global  Const  KEY'mULTIPLY  =  &H6A 
Global  Const  KEY  ADO  =  &H6B 
Global  Const  KEY'SEPARATOR  =  &H6C 
Global  Const  KEY~SUBTRACT  =  &H60 
Global  Const  KEY~DECIMAL  =  SH6E 
Global  Const  KEY~DIVIDE  -  &H6F 
Global  Const  KEY"F1  a  &H70 

Global  Const  KEY~F2  =  &H71 

Global  Const  KEY~F3  =  &H72 

Global  Const  KEY“f4  =  £H73 

Global  Const  KEY"F5  =  6H74 

Global  Const  KEY“F6  =  &H75 
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'A'  thru  'Z' 
•O'  thru  '9' 


Global  Const  KEY  F7  s  &H76 
Global  Const  KEY~F8  >  M77 
Global  Const  KEr~F9  >  &H78 
Global  Const  KEY~F10  >  tM79 
Global  Const  KEY~F11  -  tH7A 
Global  Const  KEY~F12  >  SH7B 
Global  Const  KEY~F13  ■  &H7C 
Global  Const  KEY~F14  >  &H7D 
Global  Const  KEY~F15  >  CH7E 
Global  Const  KEY~F16  >  &h7F 

Global  Const  KEY.NUNLOCK  >  &H90 

■  Variant  VarType  tags 

Global  Const  V  EMPTY  >  0 
Global  Const  V^NULL  >  1 
Global  Const  V'iNTEGER  >  2 
Global  Const  V~LONG  «  3 
Global  Const  V'SINGLE  =  4 
Global  Const  V'OOUBLE  >  5 
Global  Const  V'CURRENCY  -  6 
Global  Const  V~DATE  »  7 
Global  Const  V~STRING  >  8 


'  Event  Parameters 

'  ErrNm  (LinkError) 

Global  Const  WRONG  FORMAT  »  1 
Global  Const  ODE  SOURCE  CLOSED  >  6 
Global  Const  TOO~MANY  lTnKS  «  7 
Global  Const  0ATA_TRANSFER_FA1LE0  =  8 

'  QueryUnload 

Global  Const  FORM  CONTROLMENU  «  0 
Global  Const  FORM^COOE  «  1 
Global  Const  APP  UtNOOUS  a  2 
Global  Const  APP~TASKMANAGER  «  3 
Global  Const  FORM.MOIFORM  a  4 

'  Properties 

'  Colors 

Global  Const  BLACK  >  &H0& 

Global  Const  RED  a  &HFF& 

Global  Const  GREEN  a  &HFF00& 

Global  Const  YELLOW  a  SHFFFF& 

Global  Const  BLUE  a  &HFF0000 
Global  Const  MAGENTA  a  &HFF00FF 
Global  Const  CYAN  a  SHFFFFOO 
Global  Const  WHITE  a  &HFFFFFF 

'  System  Colors 

Global  Const  SCROLL  BARS  a  &H80000000 
Global  Const  DESKTOP  a  &HB0000001 
Global  Const  ACTIVE  TITLE  BAR  a  SH80000002 
Global  Const  INACTIVE  TITLE  BAR  a  SH80000003 
Global  Const  MENU  BAR~a  &H80OOOOO4 
Global  Const  WINDOW  BACKGROUND  a  &N8000000b 
Global  Const  WINDOW' FRAME  a  &H80000006 
Global  Const  MENU  TEXT  a  &H80000007 
Global  Const  WINDOW  TEXT  a  &H60000008 
Global  Const  TITLE_BAR_TEXT  a  &H80000009 
box.. 

Global  Const  ACTIVE  BORDER  a  &H8000000A 
Global  Const  INACTIVE  BORDER  a  &H8000D00B 
Global  Const  APPLICATTon_WORKSPACE  =  &H8000000C 
(MDI)  applications. 

Global  Const  HIGHLIGHT  a  &H8D00000D 
Global  Const  HIGHLIGHT  TEXT  a  &H8000000E 
Global  Const  BUTTON  FACE  a  SH8000000F 
Global  Const  BUTTON'SHADOW  a  &H80000010 
Global  Const  GRAY  TEXT  a  &H80000011 


•  Scroll-bars  gray  area. 

'  Desktop. 

’  Active  window  caption. 

'  Inactive  Mindow  caption. 

'  Menu  background. 

’  Window  background. 

'  Window  frame. 

'  Text  in  menus. 

'  Text  in  windows. 

'  Text  in  caption,  size  box,  scroll-bar  arrow 

'  Active  window  border. 

■  Inactive  window  border. 

'  Background  color  of  multiple  docinent  interface 

'  Items  selected  item  in  a  control. 

'  Text  of  item  selected  in  a  control. 

*  Face  shading  on  cotnaand  buttons. 

'  Edge  shading  on  coamand  buttons. 

'  Grayed  (disabled)  text.  This  color  is  set  to  0 
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if  the  current  display  driver  does  not  support  a  solid  gray  color. 
Global  Const  BUTTON_TEXT  >  tH80000012  ‘  Text  on  push  buttons. 

'  Enuwrated  Types 

'  Align  (picture  box) 

Global  Const  NONE  >  0 
Global  Const  ALIGN  TOP  «  1 
Global  Const  ALIGN~BOTTOM  >  2 

'  Alignaent 

Global  Const  LEFT  JUSTIFY  *  0  •  0  •  Left  Justify 

Global  Const  RIGHT  JUSTIFY  a  1  •  1  -  Right  Justify 

Global  Const  CENTER  a  2  •  2  •  Center 

'  BorderStyle  (form) 

■Global  Const  NONE  >  0  '  0  -  None 

Global  Const  FIXED.SINGLE  =1  •  i  ■  Fixed  Single 

Global  Const  SIZABLE  *2  ‘  2  •  Sizable  (Forms  only) 

Global  Const  FIXEO.OOUBLE  =>3  •  3  •  Fixed  Double  (Forms  only) 

'  BorderStyle  (Shape  and  Line) 

■Global  Const  TRANSPARENT  a  Q  <0  .  Transparent 

■Global  Const  SOLID  a  i  >1  -  Solid 

■Global  Const  DASH  a  2  '  2  *  Dash 

■Global  Const  DOT  a  3  ■S'  Dot 

■Global  Const  DASH  DOT  a  4  •  4  -  Dash-Dot 

■Global  Const  DASH“D0T_D0T  =  5  ■  5  -  Dash-Dot-Dot 

■Global  Const  INSIOE_SOLID  =  6  ■  6  -  Inside  Solid 

■  MousePointer 

Global  Const  DEFAULT  a  o  ■  0  •  Default 

Global  Const  ARROW  =1  ■  1  -  Arrow 

Global  Const  CROSSHAIR  a  2  ■  2  -  Cross 

Global  Const  IBEAM  a  3  ■  3  -  I-Beam 

Global  Const  ICON  POINTER  a  4  ■  4  •  Icon 

Global  Const  SIZE'poinTER  >5  •  S  •  Size 

Global  Const  SIZE'nE  SW  a  6  ■  6  -  Size  NE  SW 

Global  Const  SIZE~N  S  «  7  •  7  •  Size  N  S 

Global  Const  SIZE~NU  SE  a  8  ■  8  •  Size  HU  SE 

Global  Const  SIZE~W  fag  ■  9  -  Size  u  E 

Global  Const  UP_ARRdU  a  10  ■  10  •  Up  Arrow 

Global  Const  HOURGLASS  a  11  ■  11  -  Hourglass 

Global  Const  NO_OROP  a  12  ■  12  -  No  drop 

'  OragMode 

Global  Const  MANUAL  a  o  ■  0  -  Manual 
Global  Const  AUTOMATIC  =  1  ■  1  -  Automatic 

■  DrawMode 

Global  Const  BLACKNESS  =1  ■I  -  Blackness 

Global  Const  NOT  MERGE  PEN  =  2  ■  2  -  Not  Merge  Pen 
Global  Const  MASK  NOT  PEN  =  3  ■  3  -  Mask  Not  Pen 

Global  Const  NOT  COPY'pen  =4  ■  4  -  Not  Copy  Pen 

Global  Const  MASK  PEN'nOT  a  ;  15.  Mask  Pen  Not 

Global  Const  INVERT  =~6  ■  6  -  Invert 

Global  Const  XOR  PEN  a  7  >  7  -  Xor  Pen 

Global  Const  N0T~MASK  PEN  a  8  ■  8  -  Not  Mask  Pen 

Global  Const  MASK  PEN~a  e,  ■  9  .  Mask  Pen 

Global  Const  NOT  XOR  PEN  =10  ■  10  -  Not  Xor  Pen 

Global  Const  NOP~a  iT  ■  11  -  Nop 

Global  Const  MERGE_NOT_PEN  a  12  ■  12  -  Merge  Not  Pen 

Global  Const  COPY  PEN  =13  '  13  -  Copy  Pen 

Global  Const  MERGE  PEN  NOT  =  14  ■  14  -  Merge  Pen  Not 

Global  Const  MERGE“PEN“=  15  ■IS  -  Merge  Pen 

Global  Const  WHITENESS  =16  ■lb  -  Whiteness 

■  DrawStyle  • 

Global  Const  SOLID  =  0  ■  0  -  Solid 

Global  Const  DASH  =1  ■  1  -  Dash 

Global  Const  DOT  =2  ■  2  -  Dot 

Global  Const  DASH  DOT  =3  ■  3  -  Dash-Dot 

Global  Const  DASH~DOT  DOT  =  4  ■  4  -  Dash-Dot-Dot 

Global  Const  INVISIBLE  =5  ■  5  -  Invisible 
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Global  Const  1MSIOE_SOLID  »  6  ■  6  -  Inside  Solid 

•  FillStyle 

■  Global  Const  SOLID  >0  '  0  •  Solid 

Global  Const  TRANSPARENT  >1  ‘  1  -  Transparent 

Global  Const  HORIZONTAL  LINE  -  Z  '  Z  ■  Horizontal  Line 

Global  Const  VERTICAL_lThE  >3  '  3  -  Vertical  Line 

Global  Const  UPWARD  DIAGONAL  >4  '  4  -  Upward  Diagonal 

Global  Const  DOWNWARD  DIAGONAL  -  5  '  5  *  Downward  Diagonal 

Global  Const  CROSS  ■  2  '  6  -  Cross  I 

Global  Const  DIAGONAL_CROSS  >7  •  7  -  Diagonal  Cross 

'  LinkMode  (forms  and  controls) 

•  Global  Const  NONE  =  0  ■  0  -  None 

Global  Const  LINK  SOURCE  >1  '  1  -  Source  (forms  only) 

Global  Const  LINK''auT0MATIC  >  1  •  1  -  Automatic  (controls  only) 

Global  Const  LINK~NANUAL  >2  •  2  -  Manual  (controls  only) 

Global  Const  LINK'noTIFY  a  3  '  3  -  Notify  (controls  only) 

'  LinkMode  (kept  for  VB1.0  compatibility,  use  new  constants  instead) 

Global  Const  HOT  a  1  '  1  ■  Hot  (controls  only) 

Global  Const  SERVER  a  i  <  i  -  Server  (forms  only) 

Global  Const  COLD  =2  '  2  -  Cold  (controls  only) 


'  ScateMode 

Global  Const  USER  =  0  '  0  -  User 

Global  Const  TWIPS  a  1  '  1  •  Twip 

Global  Const  POINTS  a  2  '  2  -  Point 

Global  Const  PIXELS  a  3  •  3  -  Pixel 

Global  Const  CHARACTERS  a  4  •  4  -  Character 

Global  Const  INCHES  a  5  •  5  -  Inch 

Global  Const  MILLIMETERS  a  6  '  6  •  Millimeter 
Global  Const  CENTIMETERS  a  7  •  7  .  Centimeter 

'  ScrollBar 

•  Global  Const  NONE  a  0  '  0  •  None 
Global  Const  HIMIZONTAL  a  1  ■  1  -  Horizontal 

Global  Const  VERTICAL  a  2  ‘  2  •  Vertical 

Global  Const  BOTH  a  3  '  3  ■  Both 

'  Shape 

Global  Const  SHAPE  RECTANGLE  a  0 

Global  Const  SHAPE  SQUARE  a  1 

Global  Const  SHAPE~OVAL  a  2 

Global  Const  SHAPE^CIRCLE  a  3 

Global  Const  SHAPE  ROUNDED  RECTANGLE  a  4 

Global  Const  SHAPE^ROUNOED^SQUARE  a  5 

■  WindowState 

Global  Const  NORMAL  a  Q  •  0  -  Normal 

Global  Const  MINIMIZED  a  1  ■  1  -  Minimized 

Global  Const  MAXIMIZED  a  2  '  2  -  Maximized 

'  Check  Value 

Global  Const  UNCHECKED  a  0  '  0  -  Unchecked 

Global  Const  CHECKED  a  1  >  1  -  checked 

Global  Const  GRAYED  =2  '  2  -  Grayed 

'  Shift  parameter  masks 
Global  Const  SHIFT  MASK  a  1 
Global  Const  CTRL  MASK  a  2 
Global  Const  ALT_NASK  a  4 

■  Button  parameter  masks 

Global  Const  LEFT  BUTTON  a  1 
Global  Const  RIGHT  BUTTON  =  2 
Global  Const  MIDDLE_BUTTON  a  4  * 

'  Function  Parameters 
'  MsgBox  parameters 

Global  Const  MB_(X(  a  0  'OK  button  only 

Global  Const  MB^OKCANCEL  =1  'OK  and  Cancel  buttons 

Global  Const  MB~AB(XiTRETRYIGN(X<E  a  2  '  Abort,  Retry,  and  Ignore  buttons 
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Global  Const  tW  YESNOCANCEL  «  3 
Global  Const  NB'yESNO  *  4 
Global  Const  ra~RETRYCANCEL  >  5 

Global  Const  N8  ICONSTOP  »  16 
Global  Const  M6~I CONQUEST  ION  >  32 
Global  Const  H8~1C0NEXCLAMATI0N  -  48 
Global  Const  MB j CON IN FORMAT I ON  >  64 

Global  Const  MB  APPLMOOAL  >  0 
Global  Const  MB~DEFBUTT0N1  >  0 
Global  Const  MB''0EFBUTT0N2  ^  256 
Global  Const  NB~DEFBUTT0N3  512 
Global  Const  MbIsYSTEMMOOAL  >  4096 

'  NsgBox  return  values 
Global  Const  lOOK  *  1 

Global  Const  IDCANCEL  «  2 

Global  Const  lOABORT  =  3 

Global  Const  IDRETRY  =  4 

Global  Const  lOIGNORE  »  5 

Global  Const  IDYES  »  6 

Global  Const  IDNO  s  7 

'  SetAttr,  Oir,  GetAttr  functions 
Global  Const  ATTR  NORMAL  =  0 
Global  Const  ATTRIrEAOQNLY  »  1 
Global  Const  ATTR  HIDDEN  -  2 

Global  Const  ATTR~SYSTEN  =  4 

Global  Const  ATTR~VOLUME  >  8 

Global  Const  ATTR"D I RECTORY  =  16 
Global  Const  ATTR^ARCHIVE  »  32 

•Grid 

'ColAlignment.FixedAligrment  Properties 
Global  Const  GRID  ALIGNLEFT  D 
Global  Const  GRIO~ALIGNRIGHT  a  1 
Global  Const  GRID>LIGNCENTER  2 

•Fillstyle  Property 
Global  Const  GRID  SINL  '  »  0 
Global  Const  GRI0~REPEAT  =  1 

■OLE  Client  Control 
■Action 

Global  Const  OLE  CREATE  NEW  =  0 
Global  Const  0LE“CREATE"fR0M  FILE  =  1 
Global  Const  OLE_COPY  =  4 
Global  Const  OLE_PASTE  »  5 
Global  Const  OLE  UPDATE  -  6 
Global  Const  0LE“ACTIVATE  =  7 
Global  Const  OLEJXECUTE  =  8 
Global  Const  OLE_CLOSE  -  9 
Global  Const  OLE  DELETE  -  10 
Global  Const  0LE"SAVE  TO  FILE  =  11 
Global  Const  OLE"REAO”FR6m  FILE  =  12 
Global  Const  OLE~COMVERT_TO_TyPE  =  13 

' Server Type 

Global  Const  OLE  LINKED  =  0 
Global  Const  OLE~EMBEDDED  =  1 
Global  Const  OLE_STATIC  =  2 

■UpdateOptions 

Global  Const  OLE  AUTOMATIC  -  0 
Global  Const  OLE~FROZEN  =  1 
Global  Const  OLE~MANUAL  =  2 

■Update  Event  Constants 
Global  Const  OLE  CHANGED  =  0 
Global  Const  OLE'SAVEO  -  1 
Global  Const  OLE  CLOSED  -  2 
Global  Const  OLE~RELEASE  =  3 


■  Yes,  No,  and  Cancel  buttons 

■  Yes  and  No  buttons 

'  Retry  and  Cancel  buttons 

■  Critical  message 

■  Warning  query 

■  Warning  message 

■  Infonaation  siessage 

■  Application  Nodal  Message  Box 

■  First  button  is  default 

■  Second  button  is  default 

■  Third  button  is  default 
■System  Modal 


■  OK  button  pressed 

■  Cancel  button  pressed 

■  Abort  button  pressed 

■  Retry  button  pressed 

■  Ignore  button  pressed 

■  Yes  button  pressed 

■  No  button  pressed 
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Table  of  Contents  for  Visual  Basic  Professional 

1.  3-0  Controls 

(FraaM/Panel/Option/Check/CoMMnd/Group  Push) 

2.  Aninatad  Button 

3.  Coaiaon  Dial09  Section 

4.  Gauge  Control 

5.  Graph  Control  Section 

6.  Key  Status  Control 

7.  Spin  Button 

8.  MCI  Control  (Nultiiaedia) 

9.  Masked  Edit  Control 
to.  CoMS  Control 

11.  ODBC  Constants 


Coamon  Dialog  Control 


■Action  Property 
Global  Const  OLG  FILE  OPEN  =  1 
Global  Const  DLG~FILE  SAVE  >  2 
Global  Const  OLG~COLOR  «  3 
Global  Const  DLG~F0NT  »  4 
Global  Const  0LG~PRINT  =  5 
Global  Const  0LG_HELP  «  6 

■File  Open/Save  Dialog  Flags 
Global  Const  OFN  READONLY  <  &HU 
Global  Const  OFN~OVERURITEPROMPT  ^  tH21> 

Global  Const  OFN~HIDEREADONLY  >  &H4t 
Global  Const  OFN~NOCHANGEDIR  «  &H8B 
Global  Const  OFN~SHOUHELP  =  &H10& 

Global  Const  OFN~NOVALIDATE  »  &H100B 
Global  Const  0FN~ALL0UMULT I SELECT  >  &H200B 
Global  Const  OFN~EXTENSIONDIFFERENT  >  &H400& 

Global  Const  OFN~PATHMUSTEXIST  «  BHSOOB 
Global  Const  0FN~FILEMUSTEX1ST  >  (HlOOOt 
Global  Const  OFN~CREATEPRQ(«»T  «  &H200(M; 

Global  Const  OFN~SHAREAUARE  «  &H400M 
Global  Const  OFnInoREADONLYRETURN  -  tH8000& 

■Color  Dialog  Flags 

Global  Const  CC  RGBINIT  ^  &HU 

Global  Const  CC~FULLOPEN  >  &H2& 

Global  Const  CC~PREVENTFULLOPEN  =  &H4t 
Global  Const  CC~SHOUHELP  »  &H8& 

■Fonts  Dialog  Flags 

Global  Const  CF  SCREENFONTS  =  &H1& 

Global  Const  CF~PRINTERFONTS  -  CH2& 

Global  Const  CF~B0TH  >  &H3& 

Global  Const  CF~SHOUHELP  ^  tH4& 

Global  Const  CF~INITTOLOGFONTSTRUCT  =  &H40& 

Global  Const  CF~USESTYLE  ^  &H80& 

Global  Const  CF~EFFECTS  «  &H100& 

Global  Const  CF~APPLY  »  &K200& 

Global  Const  CF~ANSIONLY  »  &H400& 

Global  Const  CF~NOVECTORFONTS  «  &H800B 
Global  Const  CF~NOSIMULATIONS  >  BHIDOOt 
Global  Const  CF~LIMITSIZE  «  BH2000i 
Global  Const  CF~FIXEDPITCHONLY  «  &H4000& 

Global  Const  CF~UYSIUYG  »  &N8000t  ■must  also  have  CF  SCREENFONTS  & 

CF  PRIMTFRFONTS~  ~ 

Global  Const  CF  FORCEFONTEXIST  >  BH10000 
Global  Const  CF~SCALABLEONLY  ::  tH20000 
Global  Const  CF~TT0NLY  >  tH40000 
Global  Const  CF  NOFACESEL  >  BHSOOOO 
Global  Const  CF~NOSTYLESEL  *  &H100000 
Global  Const  CF~NOSIZESEL  -  &H200000 

■Printer  Dialog  Flags 

Global  Const  PD  ALLPAGES  =  &H0& 
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Global  Const  PO  SELECTION  >  UU 
Global  Const  PD~PAGENUNS  *  M2E 
Global  Const  PO~NOSELECTION  > 

Global  Const  PO~NOPAGENUMS  >  tH8t 
Global  Const  PO'COLLATE  >  (H10A 
Global  Const  PO'PRINTTOFILE  >  U20t 
Global  Const  PO~PRINTSETUP  >  tH40i 
Global  Const  PO~NOUARNING  >  tHBOi 
Global  Const  PO~RETURNOC  >  EHIOOC 
Global  Const  PO~RETURNIC  >  tH200t 
Global  Const  PO~RETURNOE FAULT  >  (H400( 

Global  Const  PD~SHOUHELP  «  iHSOOi 
Global  Const  PO'USEDEVMOOECOPIES  >  AH40000 
Global  Const  PO~OISABLEPRIHTTOFILE  -  AHaOOOO 
Global  Const  PO~HIOEPRINTTOFILE  «  &M100000 

■Help  Constants 

Global  Const  HELP  CONTEXT  >  &H1 
Global  Const  HELP''OUIT  >  tH2 
Global  Const  HELP'lNOEX  =  &H3 
Global  Const  HELP~CONTENTS  >  tH3 
Global  Const  HELP~HELPONHELP  «  tH4 
Global  Const  HELP~SETINOEX  ^  tHS 
Global  Const  HELP~SETCONTENTS  >  &H5 
Global  Const  HELP~CONTEXTPQPUP  >  tH8 
Global  Const  HELP~FORCEFILE  >  M9 
Global  Const  HELP'KEY  >  &H101 
Global  Const  HELP~COMMANO  >  M102 
Global  Const  HELP'PARTIALKEY  «  (H105 

■Error  Constants 
Global  Const  C0ERR_01ALOGFAILURE  -  AHFFFF 

Global  Const  COERR  GENERALCOOES  ^  &H0 
Global  Const  COERR'STRUCTSIZE  -  Ml 
Global  Const  COERR~INITIAL!ZATION  >  M2 
Global  Const  COERR~NOTEMPLATE  »  M3 
Global  Const  COERR~NOH INSTANCE  *  M4 
Global  Const  COERR~LOAOSTRFAILURE  «  MS 
Global  Const  COERR'FINORESFAILURE  >  I.H6 
Global  Const  COERR~LOADRESFAILURE  >  M7 
Global  Const  COERR~LOCKRESFAILURE  «  M8 
Global  Const  COERR'NENALLOCFAILURE  >  M9 
Global  Const  COERR~HEMLOCKFAILURE  «  MA 
Global  Const  COERR~NOHOOK  3  MB 

■Added  for  CNOLG.VBX 
Global  Const  COERR  CANCEL  3  MC 
Global  Const  COERR'nooLL  3  &H0 
Global  Const  COERR~ERRPROC  3  (HE 
Global  Const  COERR~ALLX  >  (hf 
Global  Const  COERR~HELP  3  M10 

Global  Const  POERR  PRINTERCOOES  3  M1000 
Global  Const  POERR~SETUPFAILURE  3  M1001 
Global  Const  POERR~PARSEFAILURE  3  M1002 
Global  Const  POERR~RETDEFFAILURE  3  M1003 
Global  Const  POERR~LOAOORVFAILURE  3  M1004 
Global  Const  POERR~GETDEVMOOEFAIL  3  M100S 
Global  Const  POERR~HiITFAILURE  3  M1006 
Global  Const  POERR~NOOEVICES  3  M1007 
Global  Const  POERR~NQOEFAULTPRN  3  M1008 
Global  Const  POERR~ONDNM  I  SNATCH  3  M1009 
Global  Const  POERRIcREATEICFAILURE  >  M100A 
Global  Const  PDERR_PRINTERNOTFOUND  3  M100B 

Global  Const  CFERR  CHOOSE FONTCOOES  3  (H2000 
Global  Const  CFERR~NOFONTS  3  (H2001 

Global  Const  FNERR  FILENAMECODES  3  M3000 
Global  Const  FNERR~SUBCLASSFAILURE  3  M3001 
Global  Const  FNERR~INVALIDFILENAME  3  M3002 
Global  Const  FNERR~BUFFERTOOSNALL  3  M3003 


■Display  topic  in  ulTopic 
■Tenainate  help 
■Display  index 

‘Display  help  on  using  help 

■Set  the  current  Index  for  aailti  index  help 


■Display  topic  for  keyword  in  offabOata 
■call  the  search  engine  in  uinhelp 


Global  Conat  FRERR  FINOREPLACECCOES  ■  tH4000 
Global  Const  CCERR'choOSECOLORCOOES  ■  MSOOO 


'Graph  Control 

I. 

'Ganaral 


Global  Const 
Global  Const 

Global  Const 
Global  Const 

Global  Const 
Global  Const 

'Graph  Types 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 


G  MORE  >  0 
G^OEFAULT  »  0 

G  OFF  ■  0 

g“om  ■  1 

G  MONO  *  0 

g”color  ■  1 


G  PIE2D  -  1 
G~PIE30  >  2 
G~BAR20  «  3 
G~BAR3D  >  4 
G'GANTT  »  5 
G'lINE  >  6 
G'LOGLIN  >  7 
G'AREA  -  8 
G”SCATTER  »  9 
G~POLAR  «  10 
G  HLC  >  11 


'Colors 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 


G  BLACK  >  0 

g“blue  «  1 

G~GREEN  >  2 
G“CYAM  *  3 
G~RE0  «  4 

g'nagenta  s  S 
G'BROWN  a  6 

g”light  gray  ■  7 

G~0ARX  GRAY  a  8 

g'lighT  blue  a  9 

G^LIGHT’CREEH  a  10 
G"LIGHT“CYAK  a  11 
G'LIGHT  red  a  12 
G*LIGHT“MAGERTA  a  13 
G”yELLOW  a  14 
G“WHITE  a  15 
G'aUTOBU  a  16 


'Patterns 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 


G  SOLID  a  0 
G~HOLLOU  a  1 
G"hATCH1  a  2 
G~HATCH2  a  3 
G“hATCH3  a  A 
G~HATCH4  a  5 
G"HATCH5  a  6 
G“hATCH6  a  7 
G~BITHAP1  a  16 
G“BITHAP2  a  17 
G~BITNAP3  a  18 
G~BITNAP4  a  19 
G~BITMAPS  a  20 
G~BITNAP6  a  21 
g"BITMAP7  a  22 
G~BITHAP8  a  23 
G~BITNAP9  a  24 
G~BITMAP1D  a  25 
G~BITMAP11  a  26 
G“BITMAP12  a  27 
G~B1TNAP13  a  28 
G'BITRAPU  a  29 
g“B1TNAP15  a  30 
C"BITMAP16  a  31 
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'Sywtools 

Global  Const  G  CROSS  PIUS  >  0 
Global  Const  G~CROSS~TIMES  >  1 
Global  Const  G~TRIAMGLE  UP  «  2 
Global  Const  G~SOLiO  TRTangLE  UP  «  3 
Global  Const  G~TRIAN6LE  DOWN  >  4 
Global  Const  G~SOLIO  TrTanglE  DOUN  >  S 
Global  Const  G~S«MRf  >  6 
Global  Const  G~SOlID  SQUARE  *  7 
Global  Const  G~DIAHOND  ■  8 
Global  Const  gIsOIID.OIAMONO  >  9 

'Lina  Styles 

'Global  Const  G  SOLID  >  0 
Global  Const  G_0ASH  «  1 
Global  Const  G  DOT  *  1 
Global  Const  G~OASHDOT  *  3 
Global  Const  g'DASHDOTDOT  «  4 

'Grids 

Global  Const  G  HORIZONTAL  =  1 
Global  Const  G~VERTICAL  <  2 

'Statistics 

Global  Const  G  MEAN  =  1 
Global  Const  G~MIN  MAX  ^  2 
Global  Const  G~ST0~0EV  -  4 
Global  Const  gIbEST.FIT  >  8 

'Data  Arrays 

Global  Const  G  GRAPH  DATA  >  1 
Global  Const  G~COLOR~DATA  »  2 
Global  Const  G~EXTRA~DATA  >  3 
Global  Const  G~LABEL~TEXT  <  4 
Global  Const  g'LEGENO  TEXT  >  5 
Global  Const  G~PATTERN  DATA  >  6 
Global  Const  G^SYMSOL  DATA  >  7 
Global  Const  G~XPOS  DATA  »  8 
Global  Const  G.ALL.OATA  *  9 

'Draw  Mode 

Global  Const  G  NO  ACTION  >  0 
Global  Const  G~CLEAR  s  1 
Global  Const  G^DRAU  «  2 
Global  Const  G  BLIT  >  3 
Global  Const  G~COPY  >  4 
Global  Const  G~PRINT  »  S 
Global  Const  G^URITE  -  6 

'Print  Options 

Global  Const  G_BOROER  ^  2 

•Pie  Chart  Options  ' 

Global  Const  G  NO  LINES  «  1 
Global  Const  G~COLORED  >  2 
Global  Const  G>ERCENTS  «  4 

'Bar  Chart  Options  ' 

'Global  Const  G  HORIZONTAL  >  1 
Global  Const  G  STACKED  =  2 
Global  Const  G~PERCENTAGE  >  4 
Global  Const  G^Z^CLUSTERED  >  6 

'Gantt  Chart  Options  ' 

Global  Const  G_SPACEO_BARS  *  1 

'Line/Polar  Chart  Options  ' 

Global  Const  G  SYMBOLS  =  1 
Global  Const  G~STICKS  2 
Global  Const  G~LINES  >  4 

'Area  Chart  Options  ' 

Global  Const  G  ABSOLUTE  »  1 
Global  Const  G^ERCENT  >  2 
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■HLC  Chart  Options 

Global  Const  G  NO  CLOSE  >  1 

Global  Const  G~NO~HIGH  LOU  *  2 


'  Agility/VB  trappable  error  codes 
'  Updated:  07- Sep-92 

Global  Const  AGIE  DBQPEN  ■  4100 
Global  Const  AGIE^OBNOTOPEN  «  4101 
Global  Const  AGIE'hOTEXIST  -  4102 
Global  Const  AGIE'noupoate  >  4103 
Global  Const  AGIE'nOOELETE  «  4104 
Global  Const  AGIE'NOADO  «  4105 
Global  Const  AGIE'BAOFILE  >  4106 
Global  Const  AGIE'NOCURPOS  ■  4107 
Global  Const  AGIE'BOUNOS  >  4108 
Global  Const  AGIE'ROUNUM  >  4109 
Global  Const  AGIE'BAOSORT  >  4110 
Global  Const  AG1E~BA0QUERY  >4111 
Global  Const  AGlE~BAOPARAM  >  4112 
Global  Const  AGIE'nopERMIT  >  4113 
Global  Const  AGIE'nARKERR  >  4114 
Global  Const  AGIE'sETERR  >  4115 
Global  Const  AGIE'RECACCESS  >  4116 
Global  Const  AGIE'FLDACCESS  >  4117 
Global  Const  AGIEJNOEXERR  >  4118 

Function  NOEV  (Mean,  SO)  As  Single 
Const  Pi  >  3.1415926536 

NOEV  >  Sqr<2  •  Log(1  /  Rnd))  *  Cos(2  *  Pi  *  Rnd)  *  SO  Mean 
End  Function 

Function  NL  ()  As  String 
NL  >  ChrSdO)  *  ChrS(13) 

End  Function 
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Cod*  For  Agt.b*s  -  databas* 

'  Agility/VB  Reteas*  001  (0.2A3)  Definitions 

'  Copyright  (C)  Apex  Software  Corporation,  1992.  All  rights  reserved. 

I 

•  **  REQUIRES  VISUAL  BASIC  2.0  •** 


'  File  Maintenance 

Declare  Sub  AgiViewOpen  Lib  "agivtaOOl .dll"  (ByVal  handC,  ByVal  vieteweeS,  ByVal  nodeS) 
Declare  Sub  AgiScheawOpen  Lib  "agivbOOl.dll"  (ByVal  hanA,  ByVal  dbhandX) 

Declare  Function  AgiFreeFile  Lib  "agivfaOOl.dll**  ()  As  Integer 
Declare  Sub  AgiViewClos*  Lib  "agivfaOOl.dll**  (ByVal  handX) 

Declare  Sub  AgiViewCloseAU  Lib  *'agivb001.dU'‘  () 

Declare  Function  AgiError  Lib  **agivfa001.dll**  ()  As  Integer 
Declare  Function  AgiErrorText  Lib  **agivt)001.dll**  ()  As  String 
Declare  Function  Agi tnternalError  Lib  *'agivb001.dll'*  ()  As  Integer 
Declare  Function  AgiVersion  Lib  *'agivfa001.dU**  ()  As  String 

'  Record  maintenance 

Declare  Sub  AgiViewOelete  Lib  '*agivb001.dll'*  (ByVal  handX) 

■  Record  data  access  and  manipulation 

Declare  Sub  AgiViewAdd  Lib  '*sgivfa001.dll*'  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 

Declare  Sub  AgiViewGet  Lib  **agivfa001  .dll**  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 

Declare  Sub  AgiViewUpdate  Lib  **agivb001.dU‘*  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 
Declare  Function  AgiViewCount  Lib  **agivfa001.dtl**  (ByVal  handX)  As  Long 

*  Ordering 

Declare  Sub  AgiViewSort  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  sortsS) 

Declare  Sub  AgiViewUnsort  Lib  "agivfaOOl.dll**  (ByVal  handX) 

Declare  Function  AgiViewSortedOn  Lib  "agivfaOOl.dll"  (ByVal  handX)  As  String 

*  Positioning 

Oeclare  Function  AgiViewFirst  Lifa  "agivfaOOl.dll"  (ByVal  handX)  As  Integer 
Oeclare  Function  AgiViewNext  Lib  "agivfaOOl.dll"  (ByVal  handX)  As  Integer 

Oeclare  Function  AgiViewLsst  Lib  "agivfaOOl.dll"  (ByVal  handX)  As  Integer 

Oeclare  Function  AgiViewPrevious  Lifa  "agivfaOOl.dll"  (ByVal  handX)  As  Integer 
Oeclare  Function  AgiViewGetRow  Lib  "agivfaOOl.dll"  (8]^al  handX)  As  Long 
Declare  Sufa  AgiViewSetRow  Lifa  "agivfaOOl.dll"  (ByVal  handX,  ByVal  roununt) 

*  Set  Selection 

Oeclare  Sub  AgiViewFind  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 

Declare  Sub  AgiVieuFindAlso  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 
Declare  Sub  AgiViewFindAll  Lib  "agivfaOOl.dll"  (ByVal  handX) 

Oeclare  Sufa  AgiViewRef ind  Lifa  "agivfaOOl.dll"  (ByVal  handX) 

Declare  Sufa  AgiViewEmptySet  Lifa  "agivfaOOl.dll"  (ByVal  handX) 

'  Set  save,  restore,  copy  and  deletion 

Declare  Sufa  AgiViewMemorizeSet  Lifa  "agivfaOOl.dll"  (ByVal  handX,  ByVal  setnameS) 

Declare  Sufa  AgiVieuRecallSet  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  setnameS) 

Oeclare  Sub  AgiViewForgetSet  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  setnameS) 

Declare  Sub  AgiViewCopySet  Lib  "agivbOOI'.dlt"  (ByVal  srchX,  ByVal  desthX) 

Declare  Sub  AgiViewOeleteSet  Lib  "agivfaOOl.dll"  (ByVal  han^) 

Oeclare  Sub  AgiViewCopyRecord  Lib  **agivb001.dll"  (ByVal  srchX,  ByVal  desthX) 

*  Mark  manipulation 

Oeclare  Sub  AgiViewMark  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  marknameS) 

Declare  Sub  AgiViewToMark  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  marknameS) 

Oeclare  Sub  AgiViewForgetMark  Lib  "agivfaOOl.dll”  (ByVal  handX,  ByVal  marknameS) 

*  Record  accunulation 

Declare  Sub  AgiViewBui IdRecord  Lib  "agivfaOOl.dll"  (ByVal  handX,  ByVal  defsS,  IpRec  As  Any) 
Declare  Function  AgiGatherData  Lib  "agivfaOOl.dll"  (ByVal  handX,  frm  As  Form)  As  Integer 


Declare  Function  AgiGatherCtlData  Lib  “agivbOOl.dU"  (ByVal  handX,  ctl  As  Control)  As  Integer 
'  Special  definitions  to  support  array  storage 

Declare  Sub  AgiViewGetArray  Lib  “agivtiOOl .dll"  Alias  "AgiViewGet"  (ByVal  handX,  ByVal  defsS, 
IpRecO  As  Any) 

Declare  Sub  AgiViewUpdateArray  Lib  “agivbOOl.dll**  Alias  "AgiVieHUpdate"  (ByVal  handX,  ByVal  defsS, 
IpRecO  As  Any) 

Declare  Sub  AgiViewAddArray  Lib  ■■agivb001.dll'*  Alias  “AgiVieuAdd**  (ByVal  handX,  ByVal  defsS, 
IpBecO  As  Any) 

Declare  Sub  AgiViewBuildRecordArray  Lib  "agivfaOOl.dtl'*  Alias  “AgiViewBui IdRecord**  (ByVal  handX, 
ByVal  defsS,  IpRecO  As  Any) 


Code  for  BctmStat  For* 


Option  Explicit 

Sub  cMdCatc.Cl ick  (} 

Dia  Node  As  String 

Oia  RecNode  As  String 

Dia  NodeCount  As  Integer 

Dia  RecCount  As  Integer 

Dia  PI  As  Double 

Dia  BaseCoeff icient  As  Single 

Dia  BaseExponent  As  Single 

Dia  PredCoeff icient  As  Single 

Dia  PredExponent  As  Single 

Dia  EstEffort  As  Double 

Dia  LogEstEffort  As  Double 

Dia  ACTEFFORT  As  Single 

Dia  LogActEffort  As  Double 

Dim  ActEffNean  As  Double 

Dim  LogActEffNean  As  Double 

Dim  BoehmHandle  As  Single 

Dim  SunActEff  As  Double 
Dim  SumLogActEff  As  Double 
Dim  SSE  As  Double 

Dim  LogSSE  As  Double 

Dim  LogSSTO  As  Double 

Dim  SunMRE  As  Double 

Dim  SumLogMRE  As  Double 

Dim  R2  As  Single 

Dim  RRMS  As  Single 

Dim  MRE  As  Single 

Dim  LogMRE  As  Single 

Dim  MREMean  As  Single 

Dim  PredLevel  As  Single 

Const  MRELimit  >  .25 
Dim  improveLevel  As  Single 

If  optOrganic. Value  *  True  Then 
Mode  »  "ORG" 

Elself  optSemiO. Value  3  True  Then 
Mode  =  ''SO'' 

Elself  optEntedded. Value  =  True  Then 
Mode  =  “E" 

Elself  optAllData. Value  3  True  Then 
Mode  *  "ALL" 

Else 

Mode  »  "UMK" 

End  If 

Mode  3  TrimfMode) 

BaseCoeff  icient  3  VaKtxtBaseCoeff  .Text) 

BaseExponent  =  Val(txtBaseExp.Text) 

PredCoeff  icient  =  VaKtxtPredCoeff  .Text) 

PredExponent  3  Val(txtPredExp.Text) 

BoehmHandle  s  OBHandle 

■AgiViewOpen  BoehmHandle,  "boehm's.dbf",  "R" 

•Debug.Prlit  AgiErrorTextO 
more  3  AgiViewFirst(BoehmHandle) 

■Find  Average  of  Actual  Efforts  in  Real  and  Log  domains 
SumActEff  3  o« 

SimLogActEff  3  0# 

ModeCount  3  0 

Do  While  more 

AgiVieuGet  BoehmHandle,  "MOOE(S)",  RecNode 
If  Mode  3  Trim(RecMode)  Or  Mode  3  «alL''  Then 
ModeCount  3  ModeCount  *  1 
'txtNumNode.Text  =  FormatSfNodeCount, 

AgiViewGet  BoehmHandle,  "ACTEFFORT (F)",  ACTEFFORT 
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SuMctEff  >  SunActEff  *  ACTEFFORT 
Suri.09ActEff  «  SuMLogActEff  «  Log(ACTEFFOfiT) 
End  If 

more  >  AgiVieMMext(BoelMiHandle) 

Loop 

If  ModeCount  >  0  Then 

ActEffMean  *  SuNActEff  /  ModeCount 
LogActEffMean  >  SuiLogActEff  /  ModeCount 

Else 

Ms^ox  "No  Records  found  with  matching  Mode.” 
Exit  Sub 
End  If 


■Caluclate  Statistics 
SSE  «  0« 

LogSSE  »  0# 

LogSSTO  -  M 
SuiMRE  -  0# 

SunLogMRE  >  0« 
Pre<A.evel  s  01 
ImproveLevel  =  0! 
RecCount  *  0 
ModeCount  a  o 


more  a  AgiViewFirstCBoehmHandle) 
txtNimMode.Text  *  FormatSfModeCount,  "IWMO") 

Do  While  more 

RecCount  a  RecCount  ♦  1 
txtNumRec.Text  3  Format$(RecCount. 

AgiViewGet  BoehmHandle,  BoehmRDS.  BoehnRec 
If  Mode  3  Trim(BoehmRec.Mode)  Or  Mode  3  "ALL"  Then 
ModeCount  3  ModeCount  +  1 
txtNuiMode.Text  3  FormatSfModeCount,  "iNMIO"} 

PI  3  BoehmRec.RELY  *  BoehmRec.OBSIZE  *  BoehmRec.CPLX  *  BoehnRec. EXTINE 
PI  3  PI  •  BoehmRec.STOR  *  BoehmRec.VIRT  *  BoehmRec.TURN  *  BoehmRec.ACAP 

PI  3  PI  *  BoehnRec.AEXP  *  BoehmRec.PCAP  *  BoehirRec.VEXP  ‘  BoehmRec.LEXP 

PI  3  PI  3  BoehnPec.NOOP  *  BoehmRec.TOOL  *  BoehmRec.SCED  *  BoehmRec.RVOL 

EstEffort  3  PI  *  predCoeff icient  *  (BoehmSec.ADJKDSI  '  PredExponent ) 
LogEstEffort  3  Log(EstEffort) 

MRE  3  Abs(BoehmRec. ACTEFFORT  •  EstEffort) 

LogMRE  3  AbslLogfBoehmRec. ACTEFFORT)  ■  LogEstEffort) 

'Calculate  sums  BoehmRec.STOR 
SSE  3  SSE  >  MRE  '  2 
LogSSE  3  LogSSE  ♦  LogMRE  '  2 

LogSSTO  3  LogSSTO  *  (Log(BoehmRec. ACTEFFORT)  -  LogActEffMean)  ‘  2 
SunMRE  3  SuiWRE  *  MRE 

If  MRE  /  BoehmRec. ACTEFFORT  <=  MRELimit  Then 
PredLevel  =  PredLevel  ♦  1# 

End  If 

If  MRE  <  AbslBoehmRec. ACTEFFORT  -  (PI  *  BaseCoeff icient  •  (BoehmRec. AD JKDS I 
BaseExponent ) ) )  Then 

ImproveLevel  =  ImproveLevel  +  1# 

End  If 
End  If 

more  3  AgiViewNext(BoehmNandle) 

Loop 

'AgiViewClose  BoehmHandle 
If  ModeCount  >  0  Then 

R2  3  1  -  (LogSSE  *  (ModeCount  -  1))  /  (LogSSTO  •  (ModeCount  -  2)) 

RRMS  3  (Sqr(SSE  /  ModeCount))  /  ActEffMean 
MREMean  s  SumMRE  /  ModeCount 
PredLevel  3  (PredLevel  /  ModeCount)  *  100 
ImproveLevel  3  (ImproveLevel  /  ModeCount)  *  100 
End  If 


Texts. Text  3  Format$(R2,  "0.0000") 

TextA.Text  3  Format$(RRNS,  "0.000") 

Texts. Text  3  Format$(MREMean,  "0.00") 

Text6.Text  3  FormatS(PredLevel,  "#0.0")  +  "X" 
Text9.Text  =  Format$( ImproveLevel,  "#0.0")  ♦  "X" 


End  Sub 
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Sub  cindCancel_Click  () 

Unload  friiistatBoehm 
End  Sub 

Sub  optEinbedded  Click  () 

txtBaseCoefT.Text  =  "2.8" 
txtBaseExp.Text  =  "1.20" 
End  Sub 

Sub  optOrganic  Click  () 

txtBaseCoeTf .Text  *  "3.2" 
txtBaseExp  =  "1.05" 

End  Sub 

Sub  optSemiD  Click  () 

txtBaseCoeff .Text  =  "3.0" 
txtBaseExp.Text  =  "1.12" 
End  Sub 


C.19 


Code  for  BhmGraph  Form 


Option  Explicit 
Option  Base  1 

Sub  c«KlCancel_Click  () 

Graphl.OataReset  >  G_All_Data 
Unload  fnnBoehaCraph~  ~ 

End  Sub 

Sub  cndNorm_Click  (} 

If  NomCtate  >  Norm_Off  Then 

cmdNorm.Caption~s  ''Normalize  Off" 

NonaState  >  Norm_On 

Else 

cskMorm. Caption  *  "Norsialize  On" 

NormState  s  Norm  Off 
End  If 

Select  Case  DBType 
Case  BoehnCB 

LoadBoehnOata  XMin.  XNax,  NormState 
Case  SampleOB 

LoadS^leOata  XHin,  XNax,  NormState 
Case  ThesisOB,  CompThesisOB 
Case  UnknownOB 
End  Select 

Graphi .OrauMode  >  G_Orau 
If  FileGraph  *  1  Then 

Graphi .OrauMode  =  G  Write 
End  If 
Erxi  Sub 

Sub  cmdZooffl_Ctick  () 

Dim  TetnpYMax  As  Single 
Dim  TempYMin  As  Single 
Dim  Tem^Max  As  Single 
Dim  TempXNin  As  Single 
Dim  Redraw  As  Integer 

Redraw  »  False 

TempYMax  -  YHax 
TempYMin  =  YMin 
TempXMax  =  XMax 
TempXMin  =  XMin 

frmZoomOata.Show  Modal 

If  XMax  <>  TempXMax  Or  XMin  <>  TempXMin  Then 
Redraw  =  True 

Graph I.DataReset  =  G_All_0ata 
Select  Case  DBType 
Case  BoehmOB 

LoadBoehnOata  XMin,  XMax,  NormState 
Case  SampleOB 

LoadSampleOata  XMin,  XMax,  NormState 
Case  ThesisOB,  CompThesisOB 
Case  UnknownOB 
End  Select 
End  If 

If  YMax  <>  TempYMax  Then 
Redraw  s  True 
Graphi .YAxisMax  =  YMax 
End  If 

If  YMin  <>  TempYMin  Then 
Redraw  =  True 
Graphi .YAxisMin  =  YMin 
End  If 

If  Redraw  Then 


C.20 


Graphi .OrawHode  >  G  Draw 
End  If 

If  FileGraph  =  1  Then 

Graphi. OrawMode  =  G  Write 
End  If 
End  Sub 

Sub  Fonn_Load  () 

txtOBName.Text  >  OBFileSpec 
Screen. MousePointer  =  HourGlass 

'set  filename  for  saving  graph 
Graphl.lmageFile  a  "behmgrph*' 

Graphi. NunPoints  a  100 

Graphi . IndexStyle  =  1  'Enhanced  index  style  permits  access  to 
'graph  2-D  arrays  for  scatter  data. 

Graphi. YAxisStyle  a  2  'Permits  user  defined  Y-origin  through  YAxisMin, 
Graphi. YAxisTicks  a  g  a  , 

'Set  default  Axis  limits  for  graph 

YMax  a  1#  'Will  increase  upon  reading  database 

YMin  a  0#  a 

XMax  a  3000#  'May  decrease  to  fit  x  range  of  data 
XMin  a  0# 

UindowState  a  Maximized 
NormState  a  Norm  Off 
Graphi. LeftTitle~a  »mh» 

Graphi .Bottom! i tie  a  "Size  in  KDSI" 

Graphi .OrawMode  -  G_0raw 

Select  Case  OBType 
Case  BoehnCB 

LoadSoehnOata  XMin,  XMax,  NormState 
Case  SampleOB 

LoadSampleOata  XMin,  XMax,  NormState 
Case  ThesisOB,  CompThesisOB 
Case  UnknowrOB 
End  Select 

Screen. MousePointer  a  HourGlass 

'Set  Y*axis  scale 
Graphi. YAxisMax  a  yMax 
Graphi .YAxisMin  =  YMin 
Graphi .OrawMode  =  G_0raw 
If  FileGraph  =  1  Then 

Graphi .OrawMode  a  o  Write 
End  If 

If  FileGraph  a  i  Then 

Graphi .OrawMode  a  o  Write 
End  If 

Screen. MousePointer  =  Oefault 
End  Sub 

Sub  LoadBo^nOata  (XLower  As  Single,  XUpper  As  Single,  Normalize  As  Integer) 
Oim  Mode  As  Integer 

Const  NunModes  =  3 
Graph I.NumSets  a  NuiModes 
Oim  I  As  Integer 

'Array  subscripting 
'  1  =  Organic  Mode 

'  2  a  Semidetached  Mode 

'  3  a  Embedded  Mode 

ReOim  ModeCount(NumModes)  As  Integer 

Oim  PI  As  Oouble 

ReOim  Coeff icient(NunModes)  As  Single 

ReOim  Exponent(NunModes)  As  Single 

ReOim  CoeffOnly(NumMocles)  As  Single 

ReOim  ExpOnly(NumModes)  As  Single 

ExpOnlyd)  =  1.05 
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ExpOnly(2)  «  1.12 
ExpOnlyO)  -  1.2 


Dim  BoehmHandle  As  Integer 

Dim  RecCount  As  Integer 


ReOin  Te«pQ(NiJiModes) 
ReOin  SuiMNQCMuiModes) 
ReOi*  SuR02(NuiModes) 
ReOin  TenpLog(NunModes) 
ReOin  TeiifCiv(HuiModes) 
ReOin  aO(NunModes) 
ReOin  al(NuModes) 
ReOin  a2(NunModes) 
ReOin  dO(NinModes) 
ReOin  dl(NuRModea) 


As  Double 
As  Double 
As  Double 
As  Double 
As  Double 
As  Integer 
As  Double 
As  Double 
As  Double 
As  Double 


'Intialize  all  aiode  arrays  to  zero 
For  I  >  1  To  NinModes 
SurMMQ(I)  «  0# 

SumQ2(I)  3  0# 

ModeCount(I)  »  0 
aid)  a  0# 
a2d)  s  0« 
dOd)  =  0« 
did)  s  0# 

Next  1 

RecCount  =  0 


BoehmHandle  ^  oBHandle 

more  =  AgiViewFirstlBoehmHandle) 

Screen. HousePointer  3  HourGlass 
Do  Uhi le  more 

AgiVieuGet  BoehmHandle,  BoehmRDS,  BoehmRec 
RecCount  >  RecCount  *  1 


'Set  appropriate  Mode  and  update  correct  ModeCount 
Select  Case  Trim(BoehnAec.Mode) 

Case  "ORG" 

Mode  s  1 
Case  "SO" 

Mode  3  2 
Case  "E" 

Mode  3  3 
Case  Else 

HsgBox  "Unrecognized  Mode  at  record  "  ♦  St r( RecCount)  + 

Mode  3  1 
End  Select 

ModeCount(Mode)  3  ModeCount  (Mode)  1 
■Calculate  the  Muliplier,  PI 

PI  3  BoehmRec. RELY  *  BoehmRec. DBS I ZE  *  BoehmRec. CPLX  *  BoehmRec. EXT  I ME 
PI  3  PI  *  BoehmRec. STOR  *  BoehmRec. VIRT  *  BoehmRec. TURN  *  BoehnRec.ACAP 

PI  3  PI  *  BoehmRec. AEXP  *  BoehmRec. PCAP  •  BoehmRec. VEXP  •  BoehmRec . LEXP 

PI  3  PI  *  BoehmRec. MOOP  *  BoehmRec. TOOL  •  BoehmRec. SCED  •  BoehmRec. RVOL 

'Calculate  sums  for  Coefficient  only 

TefflpO(Mode)  3  pi  •  (BoehmRec. AOJKOSI  '  ExpOnly(Mode)) 

SumMMa(Mode)  3  SunMMa(Mode)  >  BoehmRec. ACTEFFORT  *  TempO(Mode) 
Suii02(Mode)  3  SiinQ2(Mode)  *  Tempa(Mode)  *  TempQ(Mode) 

'Calculate  sums  for  Coefficient  and  Exponent 
TempLog(Mode)  =  Log(BoehmRec. AOJKOSI) 

TenpOiv(Mode)  3  Log(BoehmRec. ACTEFFORT  /PI) 

al(Mode)  3  al(Mode)  *  Templog(Mode) 

a2(Mode)  3  a2(Mode)  Ten^og(Mode)  *  TempLogfMode) 

dO(Mode)  3  dO(Mode)  Tempo  iv(Mode) 

dl(Mode)  3  dl(Mode)  ♦  TemiAivfMode)  •  TefflpLog(Mode) 

If  BoehmRec. AOJKOSI  >3  XLower  And  BoehmRec. AD JKDS I  <=  XUpper  Then 
'Load  Data  to  the  Graph 
Graphi .ThisSet  -  Mode 
Graph I.ThisPoint  3  ModeCount(Mode) 
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If  Normalize  Then 

Grafihl.GraphOata  >  Soehafiec.ACTEFFOilT  /  PI 

Else 

Grafihl.GraphOata  «  BoehaAec.ACTEFFOAT 
End  If 

Graphl.XPosOata  «  BoehmRec.AOJKOSI 

■Check  for  maximua  Effort  and  update  if  needed 
If  YNax  <  BoehfflRec.ACTEFFORT  Then 
YMax  -  BoehoAec. ACTE F FORT 
End  If 
End  If 

more  >  AgiVieMNextlBoehtnHandle) 

Loop 

For  I  >  1  To  NimWodes 

■Calculate  equation  parameters 
CoeffOnly(I)  >  SunMHQd)  /  SunQZd) 
aOd)  s  ModeCountd) 

Coefficientd)  *  Exp<<a2d)  *  dOd)  -  aid)  *  did))  /  (aOd)  *  a2d)  -  aid)  *  aid))) 
Exponentd)  »  (aOd)  *  did)  -  aid)  *  dOd))  /  (aOd)  *  a2d)  -  aid)  •  aid)) 

■Set  mode  characteristics 
Graphi .ThisSet  a  I 
Select  Case  I 
Case  1 

Graphi. LegendT ext  a  ■■ORG^^ 

Graphi. SynkMlOata  a  G_CROSS_PLUS 
Graphi .Col orOata  a  g_BLUE 
Case  2  ~ 

Graphi  .LegendT ext  =  ■■SO'^ 

Graphi. SynbolOata  =  G_CROSS_TIMES 
Graphi. ColorOata  =  G_GREEN  ~ 

Case  3  ~ 

Graphi. LegendT ext  a  «£« 

Graphi. SymbolData  >  G_TRIANGLE_UP 
Graphi. ColorOata  a  G_RE0 
End  Select 


Next  I 

Screen. HousePointer  =  Oefault 
End  Sub 

Sub  LoadSampleOata  (XLouer  As  Single,  XUpper  As  Single,  Normalize  As  Integer) 
Oim  Node  As  Integer 

Const  NunModes  a  i 
Graphi  .NixnSets  =  NimModes 
Oim  I  As  Integer 

■Array  subscripting 
'  1  a  Sample  Node 

ReOim  HodeCount( NunModes)  As  Integer 

Oim  PI  As  Oouble 

ReOim  Coefficientl NunModes)  As  Single 
ReOim  Exponent (NuiModes) 

Oim  SampleHandle 
Oim  RecCount 

ReOim  TempLogC NunModes) 

ReOim  TempOivl NunModes) 

ReOim  aO(NuiModes) 

ReOim  al(NunModes) 

ReOim  a2(NunModes} 

ReOim  dO(NunModes) 

ReOim  dKNuiModes) 

For  I  a  1  To  NuiModes 
ModeCountd)  =  0 
aid)  a  0# 
a2d)  a  0# 


As  Single 

As  Integer 
As  Integer 

As  Oouble 
As  Oouble 
As  Integer 
As  Oouble 
As  Oouble 
As  Oouble 
As  Oouble 
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dO(I)  >  0# 
did)  -  0« 

Next  I 

RacCount  >  0 

SanpleHandle  >  DBHandle 

more  >  AgiVieuFirst(SaMpleHandle) 

Screen. MousePointer  >  HourGlass 
Do  While  more 

AgiViewCet  SeMpleHandle,  Sa«pleR0S,  SeopleRec 
RecCount  >  RecCount  *  1 

■Set  afipropriete  Node  and  update  correct  NodeCount 
Node  «  1 

NodeCount(Node)  >  NodeCount(Node)  *  1 

'Calcualte  the  Nuliplier,  PI 
PI  >  SaapleRec.PI 

•PI  >  SanpleRec.RELY  •  SanpleRec.DBSize  *  SanplePec.CPLX  *  Sa*e>leRec.EXTII« 

•PI  >  PI  *  SanpleRec.STOR  *  SanpleRec.VIRT  *  SaopleRec.TURM  *  SaapleRec.ACAP 

•PI  >  PI  *  SampleRec.AEXP  *  SampleRec.PCAP  *  SaapleRec.VEXP  *  SanpleRec.LEXP 

•PI  3  PI  *  SaoipleRec.NOOP  •  SanpleRec.TOOL  •  SampleRec.SCED  *  SMpleRec.RVOL 

•Calculate  sums  for  Coefficient  and  Exponent 
TenpLog(Node)  -  LogfSampleRec.ACTKDSI) 

TenpOiv(Node)  -  LogCSampleRec.ACTEFFORT  /  PI) 

al(Node)  >  al(Node)  *  Teax>l.og(Node) 

a2(Node)  *  a2(Node)  *  TempLogiNode)  *  TeinpLog(Node) 

dO(Node)  -  dO(Node)  *  Ten^iv(Node) 

dl(Node)  3  dl(Node)  Tem^ivlNode)  *  TempLogfNode) 

If  SampleRec.ACTKDSI  >»  XLower  And  SampleRec.ACTKDSI  <=  XUpper  Then 
•Load  Data  to  the  Graph 
Graphl.ThisSet  =  Node 
Graphl.ThisPoint  a  NodeCount(Node) 

If  Normalize  Then 

Graphl.GraphOata  a  SampleRec.ACTEFFORT  /  PI 

Else 

Graphl.GraphOata  =  SampleRec.ACTEFFORT 
End  If 

Graph I.XPosOata  a  SampleRec.ACTKDSI 

•Check  for  maximum  Effort  and  update  if  needed 
If  YNax  <  SampleRec.ACTEFFORT  Then 
YNax  a  SampleRec.ACTEFFORT 
End  If 

End  If 

more  a  AgiViewNextlSampleHandle) 

Loop 

For  I  a  1  To  NuiModes 
a0( I )  a  NodeCount ( I ) 

Coefficientd)  a  Exp(<a2(I)  *  dOd)  -  aid)  *  did))  /  (aOd)  *  a2d)  -  aid)  •  aid))) 
Exponentd)  a  (aO<I)  *  did)  -  aid)  *  dOd))  /  (aOd)  •  a2d)  -  aid)  *  aid)) 

•Set  mode  characteristics 
Graphl.ThisSet  a  i 
Select  Case  I 
Case  1 

Graphl.LegendText  a  «SNPV^ 

Graphl.SynbolOata  a  G_CROSS_PLUS 
Graphl.ColorOata  a  g_BLUE 
Case  2 

Graphl.LegendText  a  «so^^ 

Graphi .SymbolOata  a  g_CROSS_TIHES 
Graphl.ColorOata  a  g_gREEN 
Case  3 

Graphl.LegendText  a 
Graphi. SymbolOata  a  G_TRIANGLE_UP 
Graphl.ColorOata  a  g_RED 
End  Select 
Next  I 
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ScrMn.NouscPointtr  «  Default 
End  Sub 


Cod*  for  BoehaCal  Fon* 
Sub  caidCalibrate_Cli'ck 


Oiia  Mode  As 
Diia  ModeCount  As 
Dim  RecCount  As 

Din  PI  As 
Dim  CoeffOnly  As 
Dim  ExpOnly  As 
Din  Coefficient  As 
Dim  Exponent  As 

Dim  BoehmHandle  As 

Dim  Tempo  As 
Dim  SimMMO  As 
Dim  SumQ2  As 
Dim  TempLog  As 
Dim  TempOiv  As 
Dim  aO  As 
Dim  a1  As 
Dim  a2  As 
Dim  dO  As 
Dim  d1  As 


() 

String 

Integer 

Integer 

Double 

Single 

Single 

Single 

Single 

Single 

Double 

Double 

Double 

Double 

Double 

Integer 

Double 

Double 

Double 

Double 


If  optOrganic. Value  =  True  Then 
Mode  »  “ORG“ 

ExpOnly  >  1.0S 

Elself  optSemiO. Value  -  True  Then 
Mode  -  "SO" 

ExpOnly  3  1.12 

Elself  optEfflbedded. Value  3  True  Then 
Mode  3  «E« 

ExpOnly  3  1.2 

Elself  optAllData. Value  3  True  Then 
Mode  3  kalL" 

ExpOnly  3  1.16 

Else 

Mode  3  HUNK" 

ExpOnly  3  1.16 
End  If 

BoehmHandle  3  OBHandle 

more  3  AgiVieMFirst(BoehmNandle) 

SunfWKI  3  o« 

Suna2  3  0# 

ModeCount  3  0 

txtModeTotal.Text  =  Format$(ModeCount, 

RecCount  3  0 
a1  3  0« 
a2  3  0# 
dO  3  0# 
d1  3  0# 

Do  While  more 

RecCount  3  RecCount  +  1 

txtRecTotal .Text  *  FormatSCRecCount,  "###0") 

AgiViewGet  BoehmHandle,  BoehmRDS,  BoehmRec 
If  Trim(BoehmRec.Mode)  =  TrimfMode)  Or  Mode  *  "ALL"  Then 
Mod^ount  3  ModeCount  *  1 

txtModeTotal.Text  =  Fonnat$(ModeCount,  "###0") 

PI  3  Boehnfiec.RELY  *  BoehmRec.OBSIZE  *  BoehmRec.CPLX  •  Boehidiec. EXTIME 
PI  3  PI  •  BoehfflRec.STOR  *  BoehmRec.VIRT  *  BoehmRec.TURN  *  BoehmRec.ACAP 

PI  3  PI  *  BoehfflRec.AEXP  *  BoehmRec.PCAP  *  BoehmRec.VEXP  •  BoehaAec.LEXP 

PI  3  PI  •  BoehmRec.MOOP  *  BoehnRec.TOOL  •  BoehnRec.SCED  •  BoehmRec.RVOL 

'Calculate  sums  for  Coefficient  only 
Tempo  3  PI  •  (BoehmRec.ADJKOSI  *  ExpOnly) 

SumMMO  3  SuiMMO  *  BoehmRec.ACTEFFORT  •  Tempo 
SU1102  3  Sijn02  Tempo  *  Tempo 

'Calculate  sums  for  Coefficient  and  Exponent 
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TMpl09  >  Lo9(Bo«Miec.A0JICDSI) 

Te«pOiv  «  Log(Boe»M««c.ACTEFFa«T  /  PI) 

a1  >  a1  TaaipLog 

a2  *  a2  *  TtupL^  *  Taaf)Log 

dO  3  dO  «’  TampOiv 

d1  s  d1  ♦  TeaifiOiv  *  TeaipLos 

End  If 

more  =  AgiVieMNexKBoehmHandle) 

Loop 

If  ModeCount  >  0  Then 

CoeffOnly  >  SuaMMO  /  SuBa2 
aO  >  Nod^ount 

Coefficient  ■  Exp((a2  *  dO  -  a1  *  d1)  /  (aO  *  a2  -  a1  *  a1)) 
Exponent  »  (aO  *  d1  -  a1  *  dO)  /  (aO  *  a2  -  a1  *  a1) 

End  If 

txtCoeff Only. Text  =  FormatSfCoeffOnly,  “O.OOOO”) 
txtCoeff icient.Text  s  FormatSfCoeff icient,  "O.OOOO”) 
txtExponent.Text  *  FormatSfExponent,  "0.0000") 

End  Sub 

Sub  cindCancet_Cl  ick  () 

Unload  FriiiCalBffl 
End  Sub 

Sub  Forffl_Load  O 

txtOBName.Text  »  DBFileSpec 
End  Sub 
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Code  for  BoehnOat  Foni 

Sub  CMdCancel  Click  () 

Text  1.  Text  » 

Texta.Text  -  "" 

Unload  FmBoehm 
End  Sub 

Sub  c«dFirst_Click  () 

more  *  AgiViewFirstlDBHandle) 

CoeputeEffort 
End  Sub 

Sub  c«dNext_Click  () 

more  *  AgiVieMNextCOBHandle) 

ComputeEffort 
End  Sub 

Sub  cmdP rev ious^C lick  () 

more  3  AgivTeuPrevious(DBHandle) 

ComputeEffort 
End  Sub 

Sub  ComputeEffort  () 

Dim  Multiplier  As  Double 

AgiVieuGet  OBHandle,  BoehiiAOS,  BoehmRec 
Fieldl.Text  =  BoehmRec.RELY 
Field2.Text  3  BoehmRec.DBSIZE 
Fieldl.Text  3  BoehmRec.CPLX 
FieldA.Text  *  BoetunRec.EXTtHE 
Fields. Text  3  BoehmRec.STOR 
Field6.Text  3  BoehmRec.VIRT 
Field?. Text  3  BoehmRec.TlffiN 
Fields. Text  *  BoehmRec.ACAP 
FieldD.Text  3  BoehmRec.AEXP 
FieldlO.Text  3  BoehmRec.PCAP 
Field11.Text  3  BoehmRec.VEXP 
Field12.Text  3  BoehmRec.LEXP 
Field13.Text  3  BoehmRec.NOOP 
FieldU.Text  3  BoehmRec.TOOL 
FieldlS.Text  3  BoehmRec.SCED 
Field25.Text  3  BoehmRec.RVOL 

Field16.Text  =  BoehmRec.Nus 
Field17.Text  =  BoehmRec.Year 
FieldlS.Text  =  BoehmRec . LANGUAGE 
Field19.Text  3  BoehmRec. Mode 
Field23.Text  3  BoehmRec. ESTEFFORT 

FieldZO.Text  3  BoehmRec. PI 
FieldZI.Text  3  BoehmRec. TOTKDS I 
Field22.Text  3  BoehmRec. AOJKDSI 
Field24.Text  =  BoehmRec. ACTEFFORT 

Multiplier  3  VaUFieldl .Text)  *  Val(Field2.Text)  •  VaUFieldJ.Text)  *  VaUFieldA.Text)  • 
VaUFieldS.Text)  *  Val(Field6.Text)  *  Val(Field7.Text)  •  VaUFieldS.Text) 

Multiplier  =  Multiplier  *  Val(Field9.Text}  •  Val(FieldlO.Text)  *  VaUFieldll .Text)  • 
Val(Field12.Text)  *  Val(Field13.Text)  *  VaUFieldU.Text)  *  VaKFieldlS.Text)  •  Val(Field25.Text) 
Text 1. Text  =  FormatS(Multiplier#,  "0.#0") 

Select  Case  Triffl(Field19.Text) 

Case  "ORG" 

Effort#  3  3.2  *  Val<Field22.Text)  ‘  1.05  *  Multiplier# 

Case  "SO" 

Effort#  3  3#*  Val<Field22.Text)  '  1.12  •  Multiplier# 

Case  "E" 

Effort#  3  2.S  *  Val(Field22.Text)  ‘  1.2  *  Multiplier# 

Case  Else 

'MsgBox  "Not  Reading  Node  from  Database." 

■Unload  FrmBoehm 
End  Select 

TextZ.Text  3  FormatS(Effort#,  "#,###,##0.#") 

End  Sub 
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Sub  Fonii_Load  () 

nore~*  AgiViewFirst(DBHandle) 
Campute€ffort 
End  Sub 


I 


Code  for  BoohMTbl  Fom 

Option  Explicit 

Sub  c«dCancel_Ctick  O 
Unload  frolBoatuaTable 
End  Sub 


I 


Code  for  CompCret 


Option  Explicit 

Dim  ThesisFi leSpec  As  String 

Sub  cindCancel_Cl  ick  O 

Unload  f niiConpCreate  'Close  ThesisHandle  is  in  Unload 
End  Sub 

Sub  cmdClear  Click  () 

While  AgTvieMFirst(ThesisHandle) 

AgiViewDelete  ThesisHandle 
If  AgiErrorO  <>  0  Then 

NsgBox  "Record  deletion  error:  "  *  AgiErrorTextO 
End  If 

Wend 

cffldCreate. Enabled  -  True 
cmdClear. Enabled  ^  False 
cmdSave. Enabled  =  False 
End  Sub 

Sub  ctndCreate_Cl  ick  O 

Dim  NunAec  As  Integer 

Dim  NumCheck  As  Integer 

Randomize  'Reseeds  random  ncmber  generator 

cmdClear_Click  'Clear  existing  records  if  any 

Screen. MousePointer  =  HourGlass 
NunCheck  -  0 

If  chkCID. Value  -  True  Then 
ThesisRec. Category  =  “CID" 

NunCheck  =  NumCheck  +  1 

For  NuiAec  3  1  To  Int(Val(txtBCNum.Text)) 

MakeThesisRecord  VaUtxtCIDCoeff .Text),  VaUtxtCIOExp.Text),  Val(txtCIDSO.Text) 
If  AgiErrorO  <>  0  Then 

NsgBox  "Could  not  create  record  for  Conin/I dent ificat ion." 
cmdClear_Click 

Screen. MousePointer  *  Default 
Exit  Sub 
End  If 
Next  NuiAec 
End  If 

If  chkNAV. Value  =  True  Then 
ThesisRec. Category  =  "NAV" 

NunCheck  =  NunCheck  +  1 

For  NunRec  =  1  To  IntCVaUtxtBCNun.Text)) 

MakeThesisRecord  VaKtxtNAVCoeff .Text),  Val(txtNAVExp.Text),  Val(txtNAVSD.Text) 
If  AgiErrorO  <>  0  Then 

MsgBox  "Could  not  create  record  for  Navigation  Sensors." 
cmdClear_Click 

Screen. M^sePointer  =  Default 
Exit  Sub 
End  If 
Next  NunRec 
End  If 

If  chkCAV. Value  =  True  Then 
ThesisRec. Category  =  "CAV" 

NumCheck  =  NunCheck  +  1 

For  NunRec  =  1  To  Int(Val(txtBCNun.Text)) 

MakeThesisRecord  VaKtxtCAVCoeff .Text),  VaUtxtCAVExp.Text),  Val(txtCAVSO.Text) 
If  AgiErrorO  <>  0  Then 

MsgBox  "Could  not  create  record  for  Core  Avionics." 
cmdClear_Click 

Screen. MousePointer  =  Default 
Exit  Sub 
End  If 
Next  NunRec 
End  If 

If  chkECS. Value  =  True  Then 
ThesisRec. Category  =  "ECS" 

NunCheck  -  NunCheck  *  1 

For  NunRec  =  1  To  IntCVaUtxtBCNun.Text)) 
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NakeThesisRecord  VaKtxtECSCoeff .Text),  Val(txtECSExp.Text).  VaUtxtECSSO.Text) 
If  AglErrorO  <>  0  Then 

NsgSox  “Could  not  create  record  for  Electronic  Coabat." 
cmdClear_Click 

Screen. NousePointer  3  Default 
Exit  Sub 
End  If 
Next  NuiAec 
End  If 

If  chkOFF. Value  >  True  Then 
ThesisRec. Category  *  “OFF" 

NumCheck  3  NuaCheck  *  1 

For  NumRec  3  1  To  IntCVaKtxtBCNua.Text}) 

NakeThesisRecord  VaKtxtOFFCoeff .Text),  Val(txtOFFExp.Text),  VaUtxtOFFSO.Text) 
If  AgiErrorO  <>  0  Then 

NsgBox  “Could  not  create  record  for  Offesive  Sensors." 
cffldClear_Click 

Screen. HousePointer  3  Default 
Exit  Sub 
End  If 
Next  NumRec 
End  If 

If  NumCheck  =  0  Then 

ErrMsg  =  “Please  select  at  least  one  category  from  the  check  box  list." 

NsgBox  ErrNsg 

Screen. NousePointe '  3  Default 
Exit  Sub 
End  If 

cmdCreate. Enabled  3  False 
cmdC I ear. Enabled  =  True 
cindSave. Enabled  =  True 
Screen. NousePointer  >  Default 
End  Sub 


Sub  cffldSave_Cl ick  () 

Dim  SaveHandle  As  Integer 
Dim  Filetitle  As  String 

■Get  new  FileSpec 
On  Error  Resume  Next 
CNOialogI .DefaultExt  s  "AGI" 

CNDialogl. Flags  »  OFN  PATHNUSTEXIST  +  OFN  OVERURITEPROMPT  +  OFN  HIDEREAOONLY  «’ 
OFN  EXTENSIONOIFFERENT 

“CNOialogI .Action  =  OLG_FILE_SAVE 
If  Err  =  32755  Then  ~  ”'user  selcted  cancel  button 
Exit  Sub 
End  If 

On  Error  GoTo  0 


'Test  to  see  if  neu  file  is  already  open  or  exists 
Screen. NousePointer  s  HourGlass 

If  CNDialogl. Filetitle  =  fnrtiainlCNDialogl. Filetitle  Then 
AgiViewClose  OBHandle  'Close  Open  Copy 

Kill  CNOialogI .Fi lename  'Delete  Previous  open  copy 

frmMainImnuCloseOB. Enabled  =  False  'Reset  menu  selection 
frnMainlmnuViewGraph. Enabled  =  False 
frnMain'mnuVieNTable. Enabled  =  False 
fnnNainimnuVieNOata. Visible  =  False 
fmMainlmnuCalBoehm. Enabled  =  False 
frmMainlmnuStatEval .Enabled  3  False 
Elself  CNDialogl. Filetitle  3  “CONPTHS.AGI"  Then 

Exit  Sub  'File  update  will  be  automatic  upon  Cancel_Click 

Elself  Dir$(CNDialog1. Filename)  <>  ""  Then  'If  File  exists 
Kill  CNDialogl .Fi lename  'Delete  unopened  coy 

End  If 


'  Open  blank  file  to  copy  into 

SaveHandle  =  AgiFreeFileO 

Filetitle  =  CNDialogl .Fi letitle 

Agi Vi ewOpen  SaveHandle,  Filetitle,  "CAUR" 

If  AgiErrorO  <>  0  Then 

NsgBox  "File  Creation  Error:  “  ♦  AgiErrorTextO 
End  If 


\ 
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'  Copy  current  file  into  blank  copy  for  saving 
more  s  AgiViewFi rst(ThesisHandle) 

Uhi le  more 

Ag  iViewCet  ThesisHandle,  ThesisROS,  ThesisRec 
Ag  iVieuAdd  SaveHandle,  ThesisROS,  ThesisRec 
If  AgiErrorO  <>  0  Then 

HsgBox  "Error  adding  record  to  save  file."  ♦  NLO  ♦  "File  results  undetermined." 
AgiVieuClose  (SaveHandle) 

Screen. MousePointer  =  Default 
Exit  Sub 
End  If 

more  =  AgiViewNext(ThesisHandle) 

Wend 

AgiViewClose  (SaveHandle)  'ThesisHandle  remains  open 

Screen. MousePointer  =  Default 
End  Sub 

Function  FindEDSI  (AOOKDSI  As  Double,  MOOKDSI  As  Double,  OELKDSI  As  Double)  As  Double 
'Solution  is  foimd  by  weighting  the  KDSI  values 
'These  weightings  are  from  the  Softcost-R  Manual  page  R-83 
'Note  the  wieghtings  for  lines  and  modules  have  been  added  so  as  to  include 
'the  effect  of  altering  both  the  line  and  the  module 
FindEDSI  =  .53  •  ADOKDSI  ♦  (.27  ♦  .24)  *  MOOKDSI  ♦  (.15  +  .11)  *  DELKDSI 
End  Function 

Function  FindEXi'IME  (PerTime  As  Double)  As  Double 
if  PerTime  <=  6Sit  Then 
FindEXTIME  =  1# 

Else 

FindEXTIME  =  1.82  •  (PerTime  /  100#)  ‘  1.305 
End  If 

End  Function 

Function  FindLearn  (BCNUM  As  Integer)  As  Double 

'This  function  assumes  the  realtionship  holds  true  for  6  block  changes. 

■But  SYSCON  states  relationship  holds  for  6  years. 

'Future  may  need  to  adjust  for  years  if  block  changes  are  not  1  year 
'The  exponent  comes  from  SYSCON,  Thesis  TAble  5 
If  BCNUM  >3  2  And  BCNUM  <=  6  Then 

'No  coefficient  =>  normaliie  to  1.0 

'Note  Effect  is  ratio  to  previous  BC  and  not  the  first  BC 
FindLearn  =  (BCNUM  '  (-.375))  /  ((BCNUM  -  1)  ’  (-.375)) 

Else 

FindLearn  =  1# 

End  If 

End  Function 

Function  FindSTOR  (PerMem  As  Double)  As  Double 
If  PerMem  <=  65#  Then 
FindSTOR  =  1# 

Else 

FindSTOR  =  1.94  •  (PerMem  /  100#)  '  1.425 
End  If 

End  Function 

Sub  Form_Load  ( ) 

Dim  Filetitle  As  String 
Dim  FileSpec  As  String 

'Open  new  file  (agi  formats  only). 

ThesisHandle  =  AgiFreeFi  leO 
Filetitle  =  "COMPTHS.AGI" 

AgiViewOpen  ThesisHandle,  Filetitle,  "CAUR" 

If  AgiErrorO  <>  0  Then 

MsgBox  "File  Open  Error:  "  ♦  AgiErrorText( ) 

End  If 

Tablel .ViewHandle  =  ThesisHandle 

'Enable  Appropriate  Buttons 
more  =  AgiViewFirst(ThesisHandle) 

If  more  Then 

cmdCreate. Enabled  =  False 

Else 

cmdC I  ear. Enabled  =  False 


C.33 


cndSave. Enabled  >  False 
End  If 

■Set  FileSpec  for  Save  Dial09  Box 
If  RightfFi lei. Path,  1)  <>  Then 

FileSpec  =  Filel.Path  ♦  “N"  ♦  Filetitle 

Else 

FileSpec  «  Filel.Path  Filetitle 
End  If 

CMDialogI .Fi lenaaie  a>  FileSpec  } 

End  Sub 

Sub  Form  Unload  (Cancel  As  Integer) 

AgivTewClose  ThesisHandle  . 

End  Sub 

Sub  MakeThesisRecord  (Coefficient  As  Double,  Exponent  As  Double,  StcOev  As  Double) 

Dim  NumBC  As  Integer 

Dim  EffSOPercent  As  Single 

Dim  SO  As  Single 

Dim  EAF  As  Double 

Dim  EstEffort  As  Single 

Dim  LearnEffect  As  Double 

SD  3  Val(txtFactorSO.Text) 

ThesisRec.BCNUH  =  Int((Val(txtBCNijn.Text))  *  Rnd  1) 

ThesisRec.RELY  =  NDEV(1,  SD) 

ThesisRec.DBSlZE  =  NDEV(1,  SO) 

ThesisRec.CPLX  »  NDEVd,  SD) 

ThesisRec.TIMEUTIL  =  3Dt»  «  70#  *  Rnd 

ThesisRec. EXTIME  =  FindEXTIMEfVaUThesisRec.TlMEUTR)) 

ThesisRec.MEMUTIL  =  30#  +  70#  *  Rnd 
ThesisRec.STOR  =  FindSTOR(Val(ThesisRec.NENUTtL)) 

ThesisRec. VIRT  =  N0EV(1,  SO) 

ThesisRec. TURN  =  N0EV(1,  SO) 

ThesisRec.ACAP  »  NOEVd,  SO) 

LearnEffect  *  FindLearn(Int(ThesisRec.BCNUM)) 

■Spread  Learning  Effect  to  AEXP  and  LEXP 
ThesisRec. AEXP  *  NOEVd,  SO)  *  Sqr(LearnEffect) 

ThesisRec.PCAP  «  NOEVd,  SO) 

ThesisRec. VEXP  =  NOEVd,  SO) 

ThesisRec. LEXP  =  NOEVd,  SO)  *  Sqr(LearnEffect) 

ThesisRec. HOOP  -  NOEVd,  SD) 

ThesisRec. TOOL  =  NOEVd,  SO) 

ThesisRec.SCEO  =  NOEVd,  SO) 

ThesisRec.RVOL  =  NOEVd,  SO) 

EAF  =  ThesisRec.RELY  *  ThesisRec.DBSlZE  *  ThesisRec.CPLX  *  ThesisRec. EXT  I HE 
EAF  =  EAF  •  ThesisRec.STOR  •  ThesisRec. VIRT  *  ThesisRec. TURN  •  ThesisRec.ACAP 

EAF  =  EAF  *  ThesisRec. AEXP  *  ThesisRec.PCAP  *  ThesisRec. VEXP  *  ThesisRec. LEXP 

EAF  =  EAF  *  ThesisRec. HOOP  *  ThesisRec. TOOL  •  ThesisRec.SCEO  *  ThesisRec.RVOL 

ThesisRec. PI  =  EAF 
ThesisRec. ENTROPY  »  1# 

ThesisRec. ACTKDSI  =  VaKtxtDevKOSI .Text)  *  Rnd 

ThesisRec. AOOKOSI  =  ThesisRec. ACTKDSI  *  (Val(txtPerAdd.Text)  /  100)  *  NOEVd, 

Val(txtPerSD.Text)  /  100) 

ThesisRec. HOOKDSI  =  ThesisRec. ACTKDSI  *  (Val(txtPerHod.Text)  /  100)  •  NOEVd, 

Val(txtPerSD.Text)  /  100) 

ThesisRec. DELKDSI  =  ThesisRec. ACTKDSI  *  (Val(txtPerOel.Text)  /  100)  *  NOEVd, 

Val(txtPerSO.Text)  /  100) 

ThesisRec.  EDS  I  =  FindEDSKVaUThesisRec.ADOKOSl),  VaUThesisRec. HOOKDSI), 

VaKThesisRec. DELKDSI )) 

EstEffort  =  EAF  *  Coefficient  •  (ThesisRec. ACTKDSI  '  Exponent)  *  (ThesisRec. EDSI  / 

ThesisRec. ACTKDSI) 

■EffSOPercent  is  the  X  of  SD  at  the  EDSI  value  • 

EffSOPercent  =  StdOev  /  ThesisRec. EOS I 

ThesisRec.ACTEFFORT  =  Exp(Log(EstEffort)  +  NDEV(0,  Log(1  +  EffSOPercent))) 

AgiVieuAdd  ThesisHandle,  ThesisROS,  ThesisRec 

End  Sub 

Sub  txtBCNun_LostFocus  () 

Dim  BCNUM  As  Integer 
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BCNUM  >  Int<Val(txtBCNkJii.Text)) 

If  BCNUH  >  0  Then 

txtBCNun.Text  >  Str(BCNUH) 

Else 

ErrMsg  »  "Please  select  a  positve  value  for"  ♦  MLO 
ErrMsg  »  ErrMsg  "the  nutter  of  records." 

MsgBox  ErrMsg 
txtBCNun.Text  *  "10" 
txtBCNun.  SetFocus 
End  If 
End  Sub 
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Code  for  ConpGrph  Form 


Option  Explicit 
Option  Base  1 

Sub  ciadCancel_Cliclc  () 

Graphi  .DataReset  =  G_AU_Data 
Unload  fmCompGraph 
End  Sub 

Siib  cffldNonii_Click  () 

If  Norafitate  »  Monn_Off  Then 

ctndNomi. Caption's  "Nonnalize  Off" 

HormState  *  Norm_On 

Else 

cindNorm. Caption  *  "Normalize  On" 

NormState  s  Norm  Off 
End  If 

Select  Case  DBType 
Case  BoehflOB 
Case  SampleOB 
Case  ThesisOB 
Case  CompThesisOB 

LoadConpOata  XNin,  XHax,  NormState 
Case  UnknounOB 
End  Select 

Graphi .DrauMode  s  G_Draw 
If  FileGraph  =  1  Then 

Graphi .OrawHode  =  G  Write 
End  If 
End  Sub 

Sub  cmdZooffl_Click  O 

Dim  TempYMax  As  Single 
Dim  TempYMin  As  Single 
Dim  TempXHax  As  Single 
Dim  TenpXMin  As  Single 
Dim  Redraw  As  Integer 

Redraw  -  False 

TempYMax  =  YMax 
TempYMin  =  YMin 
TempXMax  =  XMax 
TempXMin  s  XMin 

frmZoonCata.Show  Modal 

If  XMax  <>  TempXMax  Or  XMin  <>  TempXMin  Then 
Redraw  =  True 

Graphi .DataReset  =  G_All_Data 
Select  Case  DBType 
Case  BoehnOB 
Case  SampleOB 
Case  ThesisOB 
Case  CompThesisOB 

LoadCompOata  XMin,  XMax,  NormState 
Case  UnknownOB 
End  Select 
End  If 

If  YMax  <>  TempYMax  Then 
Redraw  s  True 
Graphl.YAxisMax  =  YMax 
End  If 

If  YMin  <>  TempYMin  Then 
Redraw  =  True 
Graphi .YAxisM in  ^  YMin 
End  If 

If  Redraw  Then 
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Graphi .OrawMode  s  g  Draw 
End  If 

If  FileGrapfi  *  1  Then 

Graphi .OrawMode  a  G  Write 
End  If 
End  Sub 

Sub  Forffl_Load  () 

txtOBName.Text  a  OBFileSpec 
Screen. MousePointer  a  Hourglass 

'set  filename  for  saving  graph 
Graphi. ImageFile  a  "compgrph" 

Graphi. NiaiPoints  a  lOO 

Gra^l.IndexStyle  a  i  'Enhanced  index  style  permits  access  to 
'graph  2-0  arrays  for  scatter  data. 

Graphi .YAxisS ty I e  =  2  'Permits  user  defined  V-origin  through  YAxisMin, 
Graphi .YAxisTicks  =  8 

■Set  default  Axis  limits  for  graph 

YMax  a  1#  'Will  increase  upon  reading  database 

YMin  a  0# 

XHax  a  3000#  'Hay  decrease  to  fit  x  range  of  data 
XMin  a  0# 

WindowState  a  Maximized 
NormState  a  Norm  Off 
Graphi. LeftTitle~=  "MM" 

Graphi .BottofflTi tie  a  "Size  in  EOSI" 

Graphi .OrawMode  a  G_0raw 

Select  Case  OBType 
Case  BoehnOB 
Case  SampleOB 

Case  ThesisOB,  CompThesisOB 

LoadCofflpOata  XMin,  XMax,  NormState 
Case  UnknownOB 
End  Select 

Screen. MousePointer  a  Hourglass 

'Set  Y-axis  scale 
Graphi .YAxisMax  a  YMax 
Graphi. YAxisMin  =  YMin 
Graphi .OrawMode  =  G_Draw 
If  FileGraph  =  i  Then 

Graphi. OrawMode  a  G  Write 
End  If 

Screen. MousePointer  =  Oefault 
End  Sub 

Sub  LoadCompOata  (XLower  As  Single,  XUpper  As  Single,  Normalize  As  Integer) 
Screen. MousePointer  =  Hourglass 
Oim  Mode  As  Integer 
Oim  CIOMode  As  Integer 
Oim  NAVMode  As  Integer 
Oim  CAVMode  As  Integer 
Oim  ECSMode  As  Integer 
Oim  OFFMode  As  Integer 

Oim  NunModes  As  Integer 
Const  CatPresent  a  i 
Const  CatAbsent  a  o 
Oim  CIOExist  As  Integer 
Oim  HAVExist  As  Integer 
Oim  CAVExist  As  Integer 
Oim  ECSExist  As  Integer 
Oim  OFFExist  As  Integer 

Oim  I  As  Integer 

'Array  subscripting 
'  1  a  Conn  /  10 
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'  2  «  Navigation  Sensors 

'  3  a  Core  Avionics 

'  4  a  Electronic  CoaNjst  SystesB 

'  5  a  Offensive  Sensors 

Dim  PI  As  Double 

Din  CoMpHandle  As  Integer 

Dim  RecCount  As  Integer 

CoMpHandle  a  oBHandle 

Riore  a  AgiVieMFirst(CofflpHandle) 

CIDExist  a  CatAbsent 
NAVExist  a  CatAbsent 
CAVExist  a  CatAbsent 
ECSExist  a  CatAbsent 
OFFExist  a  CatAbsent 
Do  While  more 

AgiVieuGet  CompHandle,  ThesisRDS.  ThesisRec 
Select  Case  Trim(ThesisRec. Category) 

Case  "CID" 

CIDExist  a  CatPresent 
Case  "NAV« 

NAVExist  a  CatPresent 
Case  "CAV" 

CAVExist  a  CatPresent 
Case  "ECS" 

ECSExist  a  CatPresent 
Case  "OFF" 

OFFExist  a  CatPresent 
End  Select 

n»re  a  AgiViewNext(CampHandle) 

Loop 

NunModes  a  o 
If  CIDExist  Then 

NuiModes  a  NunModes  *  1 
CIOMode  a  NunModes 
End  If 

If  NAVExist  Then 

NunModes  a  NunModes  *  1 
NAVMode  a  NunModes 
End  If 

If  CAVExist  Then 

NunModes  a  NuiModes  *  1 
CAVMode  a  NuiModes 
End  If 

If  ECSExist  Then 

NuiModes  a  NuiModes  +  1 
ECSMode  a  NunModes 
End  If 

If  OFFExist  Then 

NuiModes  a  NuiModes  *  1 
OFFMode  a  NunModes 
End  If 

■Intialize  all  mode  arrays  to  zero 
ReOiffl  ModeCount(Ni«Modes)  As  Integer 
Graphl.NunSets  a  NuiModes 
For  I  a  1  To  NuiModes 
ModeCount(I)  =  0 
Next  I 

RecCount  a  o 

more  a  AgiViewFirst(CampHandle) 

Do  While  more 

AgiViewGet  CompHandle,  ThesisRDS,  ThesisRec 
RecCount  a  RecCount  1 

'Set  appropriate  Mode  and  update  correct  ModeCount 
Select  Case  Trim(ThesisRec. Category) 

Case  "CID" 

Mode  a  CIDMode 
Case  "NAV" 
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Node  «  NAVNode 
Case  "CAV" 

Node  *  CAVNode 
Case  ••ECS" 

Node  «  ECSNode 
Case  “OFF" 

Node  *  OFFNode 
Case  Else 

NsgSox  "Unrecognized  Node  at  record  "  *  Str(RecCount)  * 
Node  >  1 
End  Select 

NodeCountlNode)  ■  NodeCount(Node)  *  1 

If  ThesisRec.EOSI  »  XLower  And  ThesisSec.EDSl  <»  XUpper  Then 
'Load  Data  to  the  Graph 
Graph I.ThisSet  *  Node 
Graphi .ThisPoint  >  NadeCount(Node) 

If  Norewlize  Then 

Graphi .GraphOata  =  ThesisRec.ACTEFFORT  /  ThesisRec.PI 

Else 

Graphi .GraphOata  >  ThesisRec.ACTEFFORT 
End  If 

Graphi. XPosOata  =  ThesisRec.EOSI 

'Check  for  maxinun  Effort  and  update  if  needed 
If  YHax  <  ThesisRec.ACTEFFORT  Then 
YNax  3  ThesisRec.ACTEFFORT 
End  If 
End  If 

more  =  AgiViewNextlCompHandle) 

Loop 

'Set  mode  characteristics 
If  CIOExist  Then 

Graph I.ThisSet  ^  CIOHode 
Graphi. LegendT ext  *  "C/ID" 

Graphi. SymbolOata  »  G_CROSS_PLUS 
Graphi. ColorOata  *  G  BLUE 
End  If 

If  NAVExist  Then 

Graphi .ThisSet  =  NAVNode 
Graphi .LegendText  =  "NAV" 

Graphi. SymbolOata  =  G_CROSS_TINES 
Graphi .ColorOata  =  G  GREEN 
End  If 

If  CAVExist  Then 

Graphi .ThisSet  =  CAVNode 
Graphi .LegendText  =  "CORE" 

Graphi. SymbolOata  s  G_TRIANGLE_UP 
Graphi .ColorOata  s  G  RED 
End  If 

If  ECSExist  Then 

Graphi .ThisSet  -  ECSNode 
Graphi .LegendText  =  "E  C" 

Graphi. SymbolOata  =  G_OIANONO 
Graphi .ColorOata  =  G  BLACK 
End  If 

If  OFFExist  Then 

Graphi .ThisSet  =  OFFNode 
Graphi .LegendText  =  "OFF" 

Graphi. SymbolOata  =  G_SOUARE 
Graphi .ColorOata  =  G  BROUN 
End  If 

Screen. NousePointer  =  Default 
End  Sub 
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Code  for  DataConv  Form 

Option  Explicit 

Sub  ci«dCancel_Click  O 
Unload  frMDataConv 
End  Sub 

Sub  cffldConvert_Clicl(  O 

Dim  SaveHa^la  As  Integer 
Dim  Filetitle  As  Strii^' 

Dim  SourceSpec  As  String 
Dim  OestSpec  As  String 
Dim  UpToExt  As  Integer 

•Filetitle  >  "GOQO.AGI** 

Filetitle  »  "SHELL. DBF" 

If  RightlFi lei .Path,  1)  <>  "\"  Then 

SourceSpec  »  Filel.Path  ♦  "\"  ♦  Filetitle 

Else 

SourceSpec  >  Filel.Path  +  Filetitle 
End  If 


■Get  new  FileSpec 

UpToExt  =  InStrlfmMainiCMOialogl. Filename,  ".") 

OestSpec  »  LeftlfmflainlCtCialogl. Filename,  UpToExt)  ♦  "DBF" 

HsgBox  "Destination  filespec  is  "  *  DestSpec 
CMDialogI .Fi lename  3  DestSpec 
■CMDialogl.DefaultExt  3  "aGI" 

CMDialogI. DefaultExt  3  «obf" 

CMDialogI. Flags  =  OFN  PATHMUSTEXIST  ♦  OFM  OVERWRITEPROMPT  ♦  OFN  HIDEREADOMLY  ♦ 
OFN_EXTENSIONDIFFERENT 
~On  Error  Resune  Next 
CMDialogI. Action  3  DLG_FILE_SAVE 

If  Err  3  32755  Then  ”  “'user  selcted  cancel  button 
Exit  Sub 
End  If 

On  Error  GoTo  0 

MsgBox  "Save  Filetitle  is  "  ♦  CMDialogI. Filetitle  ♦ 

•Test  to  see  if  new  file  is  already  open  or  exists 
Screen. MousePointer  3  HourGlass 

If  CMDialogI  .Fi  letitle  =  fmHainlCMDialogl. Filetitle  Then 
•AgiViewClose  OBHandle  'Close  Open  Copy 

•Kill  CMDialogI. Filename  'Delete  Previous  open  copy 

'frnMainlnrxjCloseDB. Enabled  *  False  'Reset  menu  selection 
'fmMainimnuViewGraph. Enabled  3  False 
'frnMain'mnuViewTable. Enabled  *  False 
'fmMain'mnuViewOata. Visible  3  False 
'fniMaininviuCalBoehm. Enabled  3  False 
'fnrMainImnuStatEval. Enabled  3  False 
■Elself  CMDialogI. Filetitle  =  "THSFILE.ACI"  Then 

'Exit  Sub  'File  update  will  be  automatic  upon  Cancel_Click 

Elself  DirS(CMDialog1. Filename)  <>  ""  Then  'If  File  exists 
Kill  CMDialogI. Filename  'Delete  unopened  coy 

End  If 

'Copy  shell. dbf  file  to  hold  new  input 
MsgBox  "SourceSpec  is  "  *  SourceSpec 
HsgBox  "DestSpec  is  "  CMDialogI. Filename 
On  Error  Resume  Next 
FileCopy  SourceSpec,  CMDialogI. Filename 
If  Err  3  55  Then  'File  already  open 

ErrMsg  =  "Cannot  copy  an  open  file.  Close  and  try  again." 

MsgBox  ErrMsg 

Screen. MousePointer  3  Default 
Exit  Sub 
End  If 

On  Error  GoTo  0 

'  Open  blank  file  in  dbase  format  to  copy  into 
SaveHandle  3  AgiFreeFi le() 

Filetitle  3  CMDialogI. Filetitle 
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AgiViewOpen  SaveHandte,  Filetitle,  "CAUR" 

If  AgiErrorO  <»  0  Than 

NsgSox  "file  Creation  Error:  "  ♦  AgiErrorTextl ) 

End  If 

'  Copy  current  file  into  blank  copy  for  saving 
'  Current  DBHandle  Must  refer  to  a  thesisOB  type 
more  *  AgiVieuFirstfOBHandle) 

Uhi  le  more 

AgiViewGet  DBHandle,  ThesisROS.  ThesisRec 
■ThesisRec.BCNUN  *  OldThesisRec.BCNUH 
•ThesisRec. CATEGORY  "  OldThesisRec. CATEGORY 
•ThesisRec. RELY  >  OldThesisRec. RELY 
• ThesisRec. DBS I ZE  "  OldThesisRec. OBSIZE 
•ThesisRec.CPLX  «  OldThesisRec. CPLX 
•ThesisRec. TINEUTIL  «  OldThestsRec.TINEUTIL 
•ThesisRec. EXTIME  >  OldThesisRec. EXTINE 
•ThesisRec.MEMUTIL  >  OldThesisRec.NENUTIL 
•ThesisRec.STOR  >  OldThesisRec.STOR 
•ThesisRec.VIRT  s  OldThesisRec. VIRT 
•ThesisRec. TURN  3  OldThesisRec. TURN 
•ThesisRec.ACAP  =  OldThesisRec. ACAP 
•ThesisRec.AEXP  =  OldThesisRec.AEXP 
•ThesisRec.PCAP  »  OldThesisRec. PCAP 
•ThesisRec.VEXP  3  OldThesisRec.VEXP 
•ThesisRec.LEXP  =  OldThesisRec.LEXP 
•ThesisRec. HOOP  •>  OldThesisRec. NOOP 
•ThesisRec. TOOL  ^  OldThesisRec. TOOL 
•ThesisRec.SCED  *  OldThesisRec. SCEO 
• ThesisRec. RVOL  3  OldThesisRec. RVOL 
•ThesisRec. PI  "  OldThesisRec. PI 
•ThesisRec. ENTROPY  =  OldThesisRec. ENTROPY 
•ThesisRec.ACTKOSI  "  OldThesisRec. ACTKOSI 
•ThesisRec. AODKDSI  3  OldThesisRec.AOOKOSI 
•ThesisRec. MOOKDSI  "  OldThesisRec. NOOKDSI 
•ThesisRec. OELKDSI  3  OldThesisRec. OELKOSI 
•ThesisRec. EDS I  3  OldThesisRec. ESDI 
•ThesisRec. ACTE F FORT  3  OldThesisRec.ACTEFFORT 

AgiViewAdd  SaveHandle,  ThesisROS,  ThesisRec 
If  AgiErrorO  <>  0  Then 

NsgBox  ••Error  adding  record  to  save  file."  ♦  NLO  ♦  "File  results  undetermined." 
AgiViewClose  (SaveHandle) 

Screen. MousePointer  3  Default 
Exit  Sub 
End  If 

more  3  AgiVieMNext(DBHandle) 

Uend 

AgiViewClose  (SaveHandle)  ‘DBHandle  remains  open 

Screen. MousePointer  =  Default 
End  Sub 

Sub  Form_Load  () 

Dim  Filetitle  As  String 
Dim  FileSpec  As  String 

‘Open  new  file  (agi  formats  only). 

‘ThesisHandle  =  AgiFreeFileO 
•Filetitle  3  "SHELL. DBF" 

‘AgiViewOpen  ThesisHandle,  Filetitle,  "CAUR" 

•If  AgiErrorO  <>  0  Then 

‘NsgSox  "File  Open  Error;  ••  ♦  AgiErrorTextO 
‘End  If 

•Tablel.ViewHandle  3  ThesisHandle 

■Enable  Appropriate  Buttons 
‘more  -  AgiViewFirst(ThesisHandle) 

' I f  more  Then 

‘cmdCreate. Enabled  3  False 
•Else 

‘cmdClear. Enabled  3  False 
‘cmdSave. Enabled  3  False 
•End  If 
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■S«t  FileSpec  for  Save  Dialog  Box 
•If  RighKFi  lei. Path.  1)  <>  "\"  Then 

•FileSpec  »  Filel.Path  ♦  ••\"  ♦  Filetitle 
•Else 

•FileSpec  s  Filel.Path  +  Filetitle 
•End  If 

•CMDialogI .Fi lenane  ^  FileSpec 
End  Sub 
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Cod*  for  OBCreate  Fort* 


Option  Explicit 

Oil*  SaitpleFi  leSpec  As  String 

Sub  cmdCancel_Ctick  () 

'ciadCle9r~Click 

Unload  frmDBCreate  'Close  SanpleHartdle  is  in  Unload 
End  Sub* 

Sub  cffldClear  Click  () 

While  AgTviewFirst(SanpleHandle) 

AgiViettfelete  SampleHartdle 
If  AgiErrorO  <>  0  Then 

HsgBox  "Record  deletion  error:  "  *  AgiErrorTextO 
End  If 

Wend 

cffldCreate. Enabled  "  True 
cffldClear.Ertabled  s  False 
cindSave. Enabled  =  False 
End  Sub 


Sub  c>*dCreate_Click  <) 
Dim  NimRec 
Dim  EffSDPercent 
Dim  SD 
Dim  EAF 
Dim  EstEffort 


As  Integer 
As  Sirtgle 
As  Single 
As  Double 
As  Sirtgle 


Randomize  'Reseeds  random  rxjtber  generator 

SO  =  Val(txtFactorSO.Text) 


cmdClear^Click  'Clear  existing  records  if  any 

Screen. MousePointer  =  HourGlass 

For  NuiAec  =  1  To  Int(txtNumRec.Text) 

Debug. Print  "Record  nuaber  "  +  StrSfMumRec) 

SampleRec.Num  =  NunRec 
SampleRec.Type  >  "XXX" 

SampIeAec.RELr  "  NOEVfl,  SD) 

SampleRec.DBSIZE  «  NDEVd,  SO) 

SmnpleRec.CPLX  »  N0EV(1,  SO) 

SmapleRec.EXTIHE  «  NDEVd,  SO) 

SampleRec.STOR  =  NDEVd,  SO) 

SampleRec.VIRT  »  NOEVd,  SO) 

SampleRec.TURN  =  NDEVd,  SO) 

SampleRec.ACAP  =  NOEVd,  SO) 

SampleRec.AEXP  "  NDEVd,  SD) 

SampleRec.PCAP  =  NDEVd,  SO) 

SampleRec.VEXP  =  NOEVd,  SO) 

SampleRec.LEXP  =  NDEVd,  SO) 

SampleRec.HOOP  =  NDEVd,  SO) 

SampleRec.TOOL  <  NDEVd,  SO) 

SampleRec.SCED  =  NDEVd,  SO) 

SanpleRec.RVOL  =  NOEVd,  SO) 

SampleRec.ACTKDSI  =  Int((Val(txtMaxKOSI .Text)  -  VaUtxtHinKDSI .Text)  1)  •  Rnd  + 
VaUtxtHinKDSI.Text)) 

EAF  ~  SampleRec.RELY  *  SampleRec.DBSIZE  *  SampleRec.CPLX  *  SampleRec.EXTIHE 
EAF  s  EAF  *  SampleRec.STOR  *  SampleRec.VIRT  •  SampleRec.TURN  *  SampleRec.ACAP 

EAF  s  EAF  *  SampleRec.AEXP  *  SampleRec.PCAP  •  SampleRec.VEXP  *  SampleRec.LEXP 

EAF  =  EAF  *  SampleRec.HOOP  *  SampleRec.TOOt.  •  SampleRec.SCED  *  SampleRec.RVOL 

SampleRec.PI  ^  EAF 

EstEffort  =  EAF  *  VaUtxtCoeff icient.Text)  •  ((SampleRec.ACTKDSI)  ‘  Val(txtExpor>ent.Text)) 
'EffSDPercent  is  the  X  of  SO  at  the  midpoint  from  Min  &  Hax  KDSI 

EffSDPercent  =  Val(txtEffortSO.Text)  /  (VaUtxtCoeff  icient.Text)  *  (((VaUtxtMinKDSI  .Text) 
*  VaUtxtMaxKDSI .Text))  /  2)  '  Val(txtExponent.Text))) 

SaepleRec.ACTEFFORT  =  Exp(Log(EstEffort)  ♦  H0EV(0.  Logd  ♦  EffSDPercent))) 

AgiViewAdd  SampleHandle,  SampleRDS,  SampleRec 
If  AgiErrorO  <>  0  Then 

MsgBox  "Could  not  add  record  ”  *  Str(NumRec)  ♦ 

cmdClear_Click 

Exit  Sub” 

End  If 
Next  NumRec 

cmdCreate. Enabled  =  False 
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cndClear.Enablad  >  True 
andSav*. Enabled  *  True 
Screen. MousePointer  >  Default 
End  Sub 

SUb  cindSave_Click  O 

Dim  SaveHandle  As  Integer 
Dim  Filetitle  As  String 

'Get  new  FileSpec 
On  Error  Resume  Next 
CMOialogl.DefaultExt  *  “AGI" 

dOialogl. Flags  >  OFN  PATHMUSTEXIST  4^  0FH_0VERWR1TEPR0MPT  *  OFN  HIDEREADONLY  « 
OFN.EXTENSIONOlr'FERENT 

CMOialogI .Action  >  DLG_F1LE_SAVE 

If  Err  =  32755  Then  ~  ~'user  selcted  cancel  button 
Exit  Sub 
End  If 

On  Error  GoTo  0 

Debug. Print  "Save  Filetitle  is  "  ♦  CMDialogl. Filetitle  ♦ 

■Test  to  see  if  new  file  is  already  open  or  exists 
Screen. MousePointer  s  HourGlass 

If  CMDialogl. Fi letitle  >  frsMainlCMDialogl .Fi letitle  Then 
AgiViewClose  DBHandle  'Close  Open  Copy 

Kill  CMDialogl. Filename  'Delete  Previous  open  copy 

fmMainlimuCloseOB. Enabled  ^  False  'Reset  menu  selection 
frtiMainlmnuViewGraph. Enabled  =  False 
frmMainlmnuViewTable. Enabled  >  False 
fmMainlmnuViewOata. Visible  =  False 
fniMainlmnuCalBoehm. Enabled  »  False 
fruMainimnuStatEval. Enabled  s  False 
Elself  CMDialogl. Filetitle  <  "NEWFILE.AGI"  Then 

Exit  Sub  'File  update  will  be  automatic  upon  Canceled ick 

Elself  DirS(CMDialog1. Filename)  <>  ***•  Then  Mf  File  exists 
Kill  CMDialogl. Filename  'Delete  unopened  coy 

End  If 

<  Open  blank  file  to  copy  into 
SaveHandle  >  AgiFreeFileO 
Filetitle  s  CMDialogl. Fi letitle 
AgiViewOpen  SaveHandle,  Filetitle,  "CAUR" 

If  AgiErrorO  <>  0  Then 

MsgBox  "File  Creation  Error:  "  ♦  AgiErrorTextO 
End  If 

'  Copy  current  file  into  blank  copy  for  saving 
more  =  AgiViewFirst(SampleHandle) 

While  more 

AgiViewGet  SampleHandle,  SampleRDS,  SampleRec 
AgiViewAdd  SaveHandle,  SampleRDS,  SampleRec 
If  AgiErrorO  <>  0  Then 

MsgBox  "Error  adding  record  to  save  file."  ♦  NLO  ♦  "File  results  undetermined." 
AgiViewClose  (SaveHandle) 

Screen. MousePointer  =  Default 
Exit  Sub 
End  If 

more  =  AgiViewNext(SampleHandle) 

Wend 

AgiViewClose  (SaveHandle)  'SaiqpleHandle  is  remains  open 

Screen. MousePointer  ^  Default 
End  Sub 

Sub  Form_Load  () 

Dim  Filetitle  As  String 
Dim  FileSpec  As  String 

'Open  new  file  (agi  formats  only). 

SampleHandle  =  AgiFreeFileO 
Filetitle  »  "NEWFILE.AGI" 

AgiViewOpen  SampleHandle,  Filetitle,  "CAUR" 

If  AgiErrorO  <>  0  Then 

MsgBox  "File  Open  Error:  "  ♦  AgiErrorTextO 
End  If 
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Tablel.ViewHandle  =  Sa«pleHandte 


'Enable  Appropriate  Buttons 
more  ■  AgiViewFirst(SampleHandle) 

If  more  Then 

cmdCreate. Enabled  =  False 

Else 

cmdClear. Enabled  >  False 
cffldSave. Enabled  -  False 
End  If 

■Set  FileSpec  for  Save  Dialog  Box 
If  RightCFi  lei. Path.  1)  <»  "V  Then 

FileSpec  »  Filel.Path  ♦  "X"  ♦  Filetitle 

Else 

FileSpec  *  Filel.Path  ♦  Filetitle 
End  If 

CMOialogl.Filenaaie  ^  FileSpec 
End  Sub 

Sub  Form  Unload  (Cancel  As  Integer} 

AgivTewCtose  SampleHandle 
End  Sub 

Sub  txtEffortSO  LostFocus  () 

If  VaUtxtEffortSO.Text)  <  0#  Then 

MsgBox  "The  Effor  Standard  Deviation  cannot  be  negative." 
txtEffortSO. Text  »  "30.0" 
txtEffortSO. Set Foe us 
txtEffortSO. SelStart  =  0 
txtEffortSD.Sel Length  •  64000 
End  If 
End  Sub 

Sub  txtNijnRec_LostFocus  () 

Dim  NunBlec  As  Integer 

NumAec  "  Int(VaUtxtNanftec.Text)) 

If  MimAec  >  0  Then 

txtNuBRec.  Text  =  StrCHunHec) 

Else 

ErrMsg  *  "Please  select  a  positve  value  for"  ♦  MLO 
ErrHsg  =  ErrMsg  ♦  "the  ni*ber  of  records." 

MsgBox  ErrMsg 
txtNiwRec.Text  =  "10" 
txtNunAec .  Set  Focus 
End  If 
End  Sub 
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Code  for  GenTable  Form 

Option  Explicit 

Sub  cmdCancel_Click  () 
Unload  frmTableOB 
End  Sub 


Code  for  Hair  hes  Form 


Option  Explicit 

Function  FindDBType  <)  As  Integer 

Dim  ValidBoehffl  As  Integer 
Dim  ValidSample  As  Integer 
Dim  ValidThesis  As  Integer* 

Dim  ValidOldThesis  As  Int^er 
Dim  ThesisCategory  As  String 
Dim  ThesisBCNum  As  Integer 

■put  record  pointer  on  first  record 
more  =  AgiViewFirstfDBHandle) 

■Check  Boehm's  original  database  structure 
AgiViewGet  DBHandle,  BoehmROS,  SoehmAec 
If  IsNulUBoehmRec.Nua)  Then 
ValidBoehm  -  False 
Elself  IsNulKBoehiiAec.Type)  Then 
ValidBoehm  »  False 

Elself  I sNul I (BoehfflRec. LANGUAGE)  Then 
ValidBoehm  =  False 
Elself  IsNulKBoehfflRec.RELY)  Then 
ValidBoehm  =  False 
Elself  IsNulKBoehmRec.DBSIZE)  Then 
ValidBoehm  =  False 
Elself  IsNulUBoehfflRec.CPLX)  Then 
ValidBoehm  =  False 
Elself  IsNulKBoehnAec.EXTIHE)  Then 
ValidBoehm  »  False 
Elself  IsNulKBoehfflBec.STOR)  Then 
ValidBoehm  *  False 
Elself  IsNulKBoehnAec.VIRT)  Then 
ValidBoehm  -  False 
Elself  I sNul I (BoehfflRec. TURN)  Then 
ValidBoehm  »  False 
Elself  IsNuU(BoehmRec.ACAP)  Then 
ValidBoehm  >  False 
Elself  I sNul I (BoehfflRec. AEXP)  Then 
ValidBoehm  ^  False 
Elself  I sNul I (BoehfflRec. PCAP)  Then 
ValidBoehm  -  False 
Elself  I sNul I (BoehfflRec. VEXP)  Then 
ValidBoehm  =  False 
Elself  IsNulKBoehfflRec.LEXP)  Then 
ValidBoehm  =  False 
Elself  IsNul l(BoehfflRec.HGOP)  Then 
ValidBoehm  =  False 
Elself  IsNul I (BoehfflRec. TOOL)  Then 
ValidBoehm  =  False 
Elself  IsNul I ( BoehfflRec. SCED)  Then 
ValidBoehm  =  False 
Elself  IsNul I (BoehfflRec. RVOL)  Then 
ValidBoehm  =  False 
Elself  IsNul I (BoehfflRec. PI)  Then 
ValidBoehm  -  False 
Elself  IsNul KBoehfflRec. Node)  Then 
ValidBoehm  =  False 
Elself  IsNulKBoehfflRec.TOTKDSI)  Then 
ValidBoehm  =  False 
Elself  IsNul I (BoehfflRec. AO JKOSI)  Then 
ValidBoehm  =  False 

Elself  IsNulKBoehfflRec. NONEFFORT)  Then 
ValidBoehm  =  False 

Elself  IsNul I (BoehfflRec. ESTEFFORT)  Then 
ValidBoehm  •  False 

Elself  IsNulKBoehfflRec. ACTEFFORT)  Then 
ValidBoehm  =  False 

Else 

ValidBoehm  =  True 
End  If 

If  ValidBoehm  Then 
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FincDBType  »  BoehnOB 

‘MsgBox  “Database  is  Boehm's  original  format." 
Exit  Function 
End  If 

■Check  Sample  database  structure 
AgiViewGet  DBHandle,  SampleRDS,  SampleRec 
If  IsNull(SaapleRec.Num)  Then 
ValidSdnple  >  False 
Elself  IsNulKSampleitec.Type)  Then 
ValidSample  »  False 
Elself  IsNulKSampleBec.RELY)  Then 
ValidSanple  >  False 
Elself  IsNulKSampleRec.DBSlZE)  Then 
ValidSample  3  False 
Elself  IsNulKSampleRec.CPLX)  Then 
ValidSample  >  False 
Elself  IsNulKSampleRec. EXTIME)  Then 
ValidSample  =  False 
Elself  IsNul USampleRec.STOR)  Then 
ValidSample  =  False 
Elself  IsNull(SampleRec.VIRT)  Then 
ValidSample  3  False 
Elself  IsNulU SampleRec. TURN)  Then 
ValidSample  3  False 
Elself  IsNulKSampleRec.ACAP)  Then 
ValidSample  3  False 
Elself  IsNull(SampleRec.AEXP)  Then 
ValidSample  3  False 
Elself  IsNul I (SampleRec. PCAP)  Then 
ValidSample  =  False 
Elself  IsNulKSampleRec.VEXP)  Then 
ValidSample  3  False 
Elself  IsNul l(SampleRec.LEXP)  Then 
ValidSample  3  False 
Elself  IsNull(SampleRec.H(X)P)  Then 
ValidSample  *  False 
Elself  IsNul l(SampleRec.T(X)L)  Then 
ValidSample  3  False 
Elself  IsNult(SampleRec.SCED)  Then 
ValidSample  3  False 
Elself  IsNul l(SampleRec.RVOL)  Then 
ValidSample  3  False 
Elself  IsNul I (SampleRec. PI)  Then 
ValidSample  3  False 
Elself  IsNull(SampleRec.ACTKDSI)  Then 
ValidSample  =  False 

Elself  IsNull(SampleRec.ACTEFFORT)  Then 
ValidSample  3  False 

Else 

ValidSample  -  True 
End  If 

If  ValidSample  Then 

FindDBType  3  SampleOB 

•MsgBox  “Database  is  in  Sample  format." 

Exit  Function 
End  If 

■Check  Thesis  database  structure 
AgiViewGet  DBHandle,  ThesisRDS,  ThesisRec 
AgiViewGet  DBHandle,  OldThesisROS,  OldThesisRec 
ValidOldThesis  -  False 
If  IsNul l(ThesisRec.BCNUM)  Then 
ValidThesis  3  False 
Elself  IsNulKThesisRec. Category)  Then 
ValidThesis  3  False 
Elself  IsNul KThesisRec. RELY)  Then 
ValidThesis  -  False 
Elself  IsNul  KThesisRec. DBSIZE)  Then 
ValidThesis  3  False 
Elself  IsNulKThesisRec. CPLX)  Then 
ValidThesis  3  False 
Elself  IsNul  KThesisRec. TIMEUTIL)  Then 
ValidThesis  3  False 
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Elself  IsNulKThesisRec. EXTINE)  Then 
ValidThcsis  *  False 
Elself  IsNulKThesisRec. MENUTIL)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec. STOR)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec. VIRT)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec. TURN)  Then 
ValidThesis  »  False 
Elself  IsNulKThesisRec.ACAP)  Then 
ValidThesis  >  False 
Elself  isNulKThesisRec.AEXP)  Then 
ValidThesis  »  False 
Elself  IsNulKThesisRec.PCAP)  Then 
ValidThesis  ■  False 
Elself  IsNulKThesisRec. VEXP)  Then 
ValidThesis  ■  False 
Elself  IsNulKThesisRec. LEXP)  Then 
ValidThesis  «  False 
Elself  IsNulKThesisRec.MOO")  Then 
ValidThesis  ^  False 
Elself  IsNulKThesisRec. TOOL)  Then 
ValidThesis  >  False 
Elself  IsNulKThesisRec. SCEO)  Then 
ValidThesis  -  False 
Elself  IsNulKThesisRec. RVOL)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec. PI)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec. ENTROPY)  Then 
ValidThesis  •  False 
Elself  IsNulKThesisRec.ACTKDSI)  Then 
ValidThesis  >  False 
Elself  IsNulKThesisRec.AOOKOSl)  Then 
ValidThesis  »  False 
Elself  isNulKThesisRec.NOOKDSI)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec.DELKDSI)  Then 
ValidThesis  *  False 
Elself  IsNulKThesisRec.EOSl)  Then 
ValidThesis  ^  False 
If  Not  IsNulKOldThesisRec.ESOl)  Then 
ValidOldThesis  3  True 
End  If 

Elself  IsNulKThesisRec. ACTEFFORT)  Then 
ValidThesis  =  False 
Else 

ValidThesis  =  True 
End  If 

If  ValidThesis  Then 

FindDBType  *  ThesisOB 

'MsgBox  "Database  is  in  Thesis  format." 

ThesisCategory  =  Trim(ThesisRec. Category) 

ThesisSCNun  =  Int<ThesisRec.8CHUM) 
more  »  AgiVieuNextlOBHandle) 

Do  While  more 

AgiVieuGet  DBHandle,  ThesisRDS,  ThesisRec  . 

If  ThesisCategory  <>  TrimlThesisRec. Category)  Or  ThesisBCNus  <>  (Int(ThesisRec.BCNWl) 

1)  Then 

FindDBType  >  CompThesisOB 

'MsgBox  "Database  is  in  composite  Thesis  format." 

Exit  Function 
End  If 

ThesisBCNum  ^  int(ThesisRec.BCNUN) 
more  ^  AgiViewNextCDBHandle) 

Loop 

Exit  Function 
End  If 

If  ValidOldThesis  Then 
FindDBType  »  ThesisDB 

MsgBox  "Database  is  in  Old  Thesis  format  and  needs  conversion." 
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End  If 


NsgBox  "Database  is  *.dbf  or  *.agi  format  but"  ♦  MLO  ♦  "record  structure  does  not  match 
required  formats." 

FindDBType  >  UnknowrOB 

End  Function 

Sub  mnuCalBoehm_Click  () 

Select  Case~OBType 
Case  BoehaOB 

FrmCalBm.ShoM 
Case  SampleOB 

FnaSampCal.ShoH 
Case  ThesisDB,  CompThesisOB 
FrmThesCal.Show 
Case  UnknowrOB 
End  Select 
End  Sub 

Sub  niiuCloseOB_Click  () 

AgiViewCloieAU 
mnuCloseOB. Enabled  "  False 
mnuViewGraph. Enabled  "  False 
mnuViewTable. Enabled  «  False 
mnuVieuOata. Visible  >  False 
mnuCalBoehm.Enabled  *  False 
mnuStatEval. Enabled  >  False 
End  Sub 

Sub  mnuCreateBoehROB_Click  O 
fniOBCreate.Shou“ 

End  Sub 

Sub  mnuCreateCofflpThesisOB_Click  () 
frmCofflpCreate.Show 
End  Sub 

Sub  mnuCreaterhesis08_Cl ick  O 
frmThsCreate.Show 
End  Sub 

Sub  mnuOataConv_Click  () 
fmOataConvTshow 
End  Sub 

Sub  mnuExit_Click  O 
AgiViewCloseAll 
End 
End  Sub 

Sub  mnuOpenOB  Click  (} 

AgiViewClMeAll  'Close  any  open  OBs  before  open  another 
On  Error  Resume  Next 
CMOialogl. Flags  =  0FM_F1LEMUSTEXIST 
CMDialogl. Action  "  DIG  FILE  OPEN 
If  Err  =  32755  Then  “  ' CDERR_CANCEL 

Exit  Sub 
End  If 

On  Error  GoTo  0 

DBFileSpec  "  CNOialogl. Filename 
DBFileName  "  CMOialogl. Filetitle 

DBHandle  >  AgiFreeFileO 
AgiViewOpen  DBHandle,  DBFileSpec,  "R" 

If  AgiErrorO  <>  0  Then 
Select  Case  AgiErrorO 
Case  AGIE  DBOPEN 

•ErrNsg  >  "Database  is  already  open." 

Case  AGIE  NOTEXIST 

ErrMsg  "  "Database  not  found.  Please  check  path  and  filename." 

Case  AGIE  BAOFILE  ^ 

ErrMsg  =  "Specified  file  is  corrupted  or"  ♦  MLO  ♦  "is  not  a  *.dbf  or  .agi  file 
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format." 


Casa  Else 

ErrMsg  >  AgiErrorTextO 
End  Select 

HsgSox  ErrNsg  ♦  ML()  ♦  "Error#;  "  ♦  Str(AgiError()) 


Else 

more  a  AgiVieMFirst(DBHandle) 

If  more  Then 

mnuC I oseOB. Enabled  >  True 
DBType  X  FlndDBTypeO 
Select  Case  DBType 
Cese  BoehaOB 

mnUV I euGraph. Enabled  «  True 
anuVIewTable. Enabled  *  True 
mnuVieMOata. Visible  *  True 
mnuCa I Boehm. Enabled  >  True 
mnuStatEval. Enabled  «  True 
Case  SeeplcOB 

mnuViewGraph. Enabled  >  True 
mnuViewTable. Enabled  >  True 
snUVieMOata. Visible  >  False 
mnuCalBoehm.Enabled  >  True 
mnuStatEval .Enabled  *  False 
Case  ThesisOB,  CoepThesisOB 
mnuViewGraph. Enabled  >  True 
mnuViewTable. Enabled  *  True 
mnuViewOata. Visible  *  False 
mnuCalBoehm.Enabled  *  True 
mnuStatEval. Enabled  »  True 
Case  UnknownOB 

ErrMsg  a  "Format  of  selected  database  is  not  recognizeable."  *  NLO 
ErrMsg  *  ErrMsg  ♦  "Only  viewing  is  permitted." 

MsgBox  ErrMsg 

mnuViewGraph. Enabled  a  False 
mnuViewTable. Enabled  =  True 
mnuViewOata. Visible  a  False 
mnuCalBoehm.Enabled  a  False 
mnuStatEval .Enabled  a  False 
End  Select 

Else 

AgiViewClose  OBHandle 

ErrMsg  a  "Database  exists  but  has  zero  records." 

MsgBox  ErrMsg 
End  If 
End  If 
End  Sub 

Sub  mnuStatEval_Click  () 

Select  Case~OBType 
Case  BoehnOB 

frsiStatBoehm.Show 
Case  SampleOB 
Case  ThesisOB 

frmThesStat.Show 
Case  CompThesisOB 
frmThesStat.Show 
Case  UnknownOB 
End  Select 
End  Sub 

Sub  mnuViewOata_Cl ick  O 
FrmBoehffl.Shw 
End  Sub 

Sub  mnUViewGraph_Click  () 

Select  Case  DBType 
Case  BoehflCB 

f  rmBoehmGraph . Show 
Case  SampleOB 

f rmBoehmGraph . Show 
Case  ThesisOB 

f  rmThesGr aph . Show 
Case  CompThesisOB 


C.51 


f  nCoapCr  a|)l« .  Show 
Cas*  UnknowrOB 
End  Salact 
End  Sub 

Sub  MnuViawTabla_Cl<ck  () 

Salact  Casa  OBTypa 
Casa  BoaMB 

frsAoah«Tabla.txtOBNaiM.Text*«  OBFilaSpac 
'frsAoaNaTabla.Tablel.FllaNaaw  >  OBFilaSpac 
frsfloatMTabla.Tablel.ViaHHandla  3  OBHandle 
f  mSoehaiT  abl  e .  Show 
Casa  SastplaOB 

frMSampTabla.txtOBNaM.Taxt  -  OBFilaSpac 
fnaSaapTabla.Tablal.FilaNaM  >  OBFilaSpac 
friaSaayTabla.Tablal.ViawWaodla  «  OBHandle 
f  naSaaipTabl  a .  Show 
Casa  ThesisOB,  CoapThasisOB 

frmThesTabla.txtDBHaM.Taxt  ■  OBFilaSpac 
frmThesTable.Tafalel.VieMHandle  >  OBHa^te 
f rmThesTabl e . Show 
Case  UnknowrOB 

frmTableOB.txtOBNaM.Text  «  OBFileSpec 
frmTableOB.Tablel.ViewHandle  3  OBHandle 
frmTableOB.Show 
End  Select 
End  Sub 
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Code  for  SampCal  Form 
Option  Explicit 


Sub  csidCalibrate  Click 

() 

Dim 

Node 

As 

string 

Dim 

NodeCount 

As 

Integer 

Dim 

RecCount 

As 

Integer 

Dim 

CoeffOnly 

As 

Single 

Dim 

ExpOnly 

As 

Single 

Dim 

Coefficient  As 

Single 

Dim 

Exponent 

As 

Single 

Dim 

Tempo 

As 

Double 

Dim 

SimMHO 

As 

Double 

Dim 

Suma2 

As 

Double 

Dim 

TempLog 

As 

Double 

Dim 

TempOiv 

As 

Double 

Dim 

aO 

As 

Integer 

Dim 

a1 

As 

Double 

Dim 

a2 

As 

Double 

Dim 

dO 

As 

Double 

Dim 

d1 

As 

Double 

If  optOr panic. Value  *  True  Then 
Node  -  "ORG* 

ExpOnly  >  1.0S 

Elsetf  optScmiO. Value  «  True  Then 
Node  ■  "SO" 

ExpOnly  >1.12 

Elsetf  optEntoedded. Value  >  True  Then 
Node  =  "E" 

ExpOnly  >  1.2 

Elself  optAllData. Value  >  True  Then 
Node  >  "ALL" 

ExpOnly  >1.16 

Else 

Node  «  "UNK” 

ExpOnly  >1.16 
End  If 

Samplettardle  >  OBHandle 

more  >  AgiVieMFirstlSampleHandle) 

SwMHQ  >  0# 

Sum02  >  0« 

NodeCount  =  0 

txtNodeTotal .Text  >  Format$(NodeCount, 

RecCount  >  0 
a1  >  0« 
a2  >  0« 
dO  >  0# 
d1  >  0# 

Do  While  more 

RecCount  >  RecCount  *  1 

txtRecTotal.Text  >  Format$(RecCount,  "BMIO") 

AgiViewGet  SampleHandle,  SampleROS,  SampleRec 
If  Trim( SampleRec. Type)  >  Trim<Node)  Or  Node  =  "ALL”  Then 
Nod^ount  >  Nod^ount  1 

txtNodeTotal. Text  >  FormatSCNodeCount,  "MUfO") 

■Calculate  sues  for  Coefficient  only 
Tempo  >  SampleRec. PI  "  (SampleRec.ACTKDSI  '  ExpOnly) 
SuoMHQ  >  StiilRW  SampleRec. ACTEFFORT  *  Tempo 

Sum02  >  SUII02  *  Tempo  •  Tempo 

■Calculate  sums  for  Coefficient  and  Exponent 
TempLog  >  Log(SampleRec.ACTKOSI) 

Tem^iv  >  LogfSampleRec. ACTEFFORT  /  SampleRec. PI) 
a1  >  a1  Tem^og 
a2  >  a2  TempLog  *  TempLog 
dO  >  dO  TempOiv 
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d1  >  d1  >  TenpDiv  *  TenpLog 


End  If 

mor*  «  AgiViewHext(Saiiv>leNandle) 

Loop 

If  ModtCount  >  0  Then 

CoeffOnly  >  SinMMO  /  SuMa2 
aO  •  Ho<Mount 

Coefficient  •  Exp((a2  *  dO  -  a1  *  d1)  /  (aO  •  a2  -  a1  *  a1)) 
Exponent  »  <a0  *  d1  -  a1  *  dO)  /  (aO  *  a2  -  a1  •  a1) 

End  If 

txtCoeffOnly.Text  »  FornatSfCoeffOnly,  “0.0000") 
txtCoefficient.Text  ■  FonaatSCCoefficient,  “0.0000") 
txtExponent.Text  »  Format$(Exponent,  "0.0000") 

End  Sub 

Sub  cindCancel_Click  () 

Unload  FrinSampCal 
End  Sub 

Sub  Fonii_Load  () 

txtOBName.Text  “  DBFileSpec 
End  Sub 
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Cod*  for  SampTbl  Form 

Option  Explicit 

Sub  cmdCanc*l_Clicl(  (} 
Unload  frmSampTable 
End  Sub 


Code  for  ThesCal  Form 

Option  Explicit 

Sub  cmdCalibrate_Click  () 


Dim  Category~ 

As  String 

Dim  CategoryCount  As  Integer 

Dim  RecCount 

As  Integer 

Dim  CoeffOnly 

As 

Single 

Dim  ExpOnly 

As 

Single 

Dim  Coefficient 

As 

Single 

Dim  Exponent 

As 

Single 

Dim  BCT 

As 

Double 

Dim  Tempo 

As 

Double 

Dim  SuiMMO 

As 

Double 

Dim  Sijn02 

As 

Double 

Dim  TempLog 

As 

Double 

Dim  TempOiv 

As 

Double 

Dim  aO 

As 

Integer 

Dim  a1 

As 

Double 

Dim  a2 

As 

Double 

Dim  dO 

As 

Double 

Dim  d1 

As 

Double 

If  optCID. Value  =  True  Then 
Category  =  "CIO" 

ExpOnly  >  1.05 

Elself  optNAV. Value  >  True  Then 
Category  »  "MAV" 

ExpOnly  »  1.12 

Elself  optCAV. Value  »  True  Then 
Category  =  "CAV" 

ExpOnly  *1.2 

Elself  optECS. Value  z  True  Then 
Category  »  "ECS" 

ExpOnly  »  1.28 

Elself  optOFF. Value  s  True  Then 
Category  »  "OFF" 

ExpOnly  s  1.36 

Elself  optAllOata. Value  >  True  Then 
Category  =  "ALL" 

ExpOnly  =1.16 

Else 

Category  =  "UMK" 

ExpOnly  =1.16 
End  If 

ThesisHandle  =  OBHandle 

more  =  AgiViewFirst(ThesisHandle) 

SunMMQ  =  0# 

SumQ2  =  0# 

CategoryCount  =  0 

txtCategoryTotal.Text  =  FormatSC CategoryCount,  "HtthlfO") 

RecCount  =  0 
a1  =  0# 
a2  =  0# 
dO  =  0# 
d1  =  0# 

Do  While  more 

RecCount  =  RecCount  1 

txtRecTotal.Text  =  FormatS(RecCount,  "###0") 

AgiViewGet  ThesisHandle,  ThesisROS,  ThesfsRec 

If  Trim(ThesisRec. Category)  =  TrimfCategory)  Or  Category  »  "ALL"  Then 
CategoryCount  =  CategoryCount  *  1 
txtCategoryTotal.Text  =  FormatS(CategoryCount, 

'Calculate  sums  for  Coefficient  only 

BCT  =  ThesisRec.EDSI  /  ThesisRec.ACTKDSI 

Tempo  =  ThesisRec.PI  *  (ThesisRec.ACTKDSI  '  ExpOnly)  *  BCT 

SurMMO  =  SuifWO  ThesisRec.ACTEFFORT  *  Tempo 
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SumOZ  z  SiMOZ  *  TenpQ  *  TenpQ 


■Calculate  sues  for  Coefficient  and  Exponent 
TenpLog  >  LogfThesisRec.ACTKDSl ) 

Te)iiii)iv  *  log(ThesisRec.ACTEFFORT  /  (ThesisRec.PI  *  BCT)) 

a1  «  a1  >  Tem^og 

aZ  *  a2  *  Ten^og  *  TempLog 

dO  s  dO  +  Teniiliv 

d1  z  d1  TeeifAiv  *  TempLog 

End  If 

more  >  AgiViewNext(ThesisHandle) 

Loop 

If  CategoryCount  >  0  Then 

CoeffOnly  s  SurMMQ  /  SunOZ 
aO  3  CategoryCount 

Coefficient  =  Exp((aZ  *  dO  -  a1  *  d1)  /  (aO  *  aZ  -  a1  •  a1)) 
Exponent  =  (aO  *  d1  -  a1  *  dO)  /  (aO  •  aZ  -  a1  *  a1) 

End  If 

txtCoeffOnly.Text  »  FormatSfCoeffOnly,  “0.0000") 
txtCoeff icient.Text  =  FomiatSfCoeff icient,  "0.0000") 
txtExponent.Text  a  Format$<Exponent,  “0.0000“) 

End  Sub 

Sub  cffldCancel_Click  () 

Unload  frmThesCal 
End  Sub 

Sub  Fonii_Load  () 

txtOBName.Text  a  DBFileSpec 
End  Sub 
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Code  for  ThesStat  Form 


Option  Explicit 

Sub  cindCalc_Click  () 

Dim  Category  As  String 

Dim  RecCategory  As  String 

Dim  CategoryCount  As  Integer 

Dim  RecCount  As  Integer 

Dim  PI  As  Double 

Dim  BaseCoeff icient  As  Single 

Dim  BaseExponmt  As  Single 

Dim  PredCoeff icient  As  Single 

Dim  PredExponent  As  Single 

Dim  EstEffort  As  Double 

Dim  LogEstEffort  As  Double 

Dim  ACTEFFORT  As  Single 

Dim  LogActEffort  As  Double 

Dim  ActEffHean  As  Double 

Dim  LogActEffMean  As  Double 

Dim  ThesisHandle  As  Single 

Dim  SumActEff  As  Double 
Dim  SumLogActEff  As  Double 
Dim  SSE  As  Double 

Dim  LogSSE  As  Double 

Dim  LogSSTO  As  Double 

Dim  SuiMRE  As  Double 

Dim  SunLogMRE  As  Double 

Dim  R2  As  Single 

Dim  RRMS  As  Single 

Dim  HRE  As  Single 

Dim  LogMRE  As  Single 

Dim  MREMean  As  Single 

Dim. PredLevel  As  Single 
Const  MRELimit  ^  .25 
Dim  ImproveLevel  As  Single 

If  optCID. Value  »  True  Then 
Category  =  "CID" 

Elself  optNAV. Value  =  True  Then 
Category  =  "NAV" 

Elself  optCAV. Value  »  True  Then 
Category  =  "CAV" 

Elself  optECS. Value  =  True  Then 
Category  =  "ECS" 

Elself  optoM. Value  =  True  Then 
Category  =  "OFF" 

Elself  optAl IData. Value  =  True  Then 
Category  =  "ALL" 

Else 

Category  *  "UNK" 

End  If 

Category  *  Trim(Category) 

BaseCoeff  icient  =  VaUtxtBaseCoeff  .Text) 

BaseExponent  s  VaUtxtBaseExp.Text) 

PredCoeff  icient  =  VaKtxtPredCoef  f  .Text) 

PredExponent  =  Val(txtPredExp.Text) 

ThesisHandle  =  DBHandle 

■AgiViewOpen  BoehmHandle,  "boehm's.dbf",  "R" 

■Debug. Print  AgiErrorTextO 

■Find  Average  of  Actual  Efforts  in  Real  and  Log  domains 
SumActEff  -  0# 

SumLogActEff  =  0# 

CategoryCount  =  0 

more  =  AgiViewFirst(ThesisHandle) 

Do  While  more 

AgiViewGet  ThesisHandle,  "CATEGORY(S)",  RecCategory 
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If  Category  >  TrimfRecCategory)  Or  Category  «  "ALL"  Then 
CategoryCount  >  CategoryCount  *  1 
■txtNuiMode.Text  *  FormatSf CategoryCount, 

AgiViewGet  ThesisHandle,  "ACTEFFQRTCF)",  ACTEFFORT 
SuMctEff  >  SunActEff  ACTEFFORT 
SunLogActEff  ^  SumLogActEff  +  Log(ACTEFFORT) 

End  If 

more  >  AgiVieuNext(ThesisHandle) 

Loop 

If  CategoryCount  >  0  Then 

ActEffNean  »  SumActEff  /  CategoryCount 
LogActEffMean  ^  SumLogActEff  /  CategoryCount 

Else 

MsgBox  “No  Records  found  with  matching  Node." 

Exit  Sub 
End  If 

'Caluclate  Statistics 
SSE  s  0# 

LogSSE  -  0# 

LogSSTO  =  0# 

SunMRE  >  0# 

SumLogMRE  ^  0# 

PredLevel  s  01 
ImproveLevel  »  O! 

RecCount  3  0 
CategoryCount  «  o 

more  =  AgiViewFirst(ThesisHandle) 
txtNuiMode.Text  =  FormatSlCategoryCount, 

Oo  While  more 

RecCount  »  RecCount  *  1 

txtNunRec.Text  =  FormatSl RecCount,  “ftlWO”) 

AgiViewGet  ThesisHandle,  ThesisRDS,  ThesisRec 
If  Category  »  Trim(ThesisRec. Category)  Or  Category  =  "ALL"  Then 
CategoryCount  s  CategoryCount  *  1 
txtNutiMode.Text  >  Format$(CategoryCount,  ”###0") 

•PI  3  BoehfflRec.RELY  *  BoehmRec.OBSIZE  *  BoehmRec.CPLX  *  BoehnAec.EXTIME 
•PI  3  PI  *  BoehmRec.STOR  *  BoehmRec.VlRT  *  BoehmRec.TURN  *  BoehmRec.ACAP 

•PI  3  PI  *  BoehmRec.AEXP  *  BoehmRec.PCAP  *  BoehmRec.VEXP  *  BoehnRec.LEXP 

•PI  3  PI  *  BoehmRec.MOOP  *  BoehnRec.TOOL  *  BoehnRec.SCED  •  BoehmRec.RVOL 

EstEffort  *  ThesisRec. PI  •  PredCoefficient  *  (ThesisRec. ACTXDSI  ‘  PredExponent)  * 

(ThesisRec. EDSI  /  ThesisRec.ACTKOSO 

LogEstEffort  =  Log(EstEffort) 

MRE  3  Abs(ThesisRec.ACTEFFORT  •  EstEffort) 

LogMRE  =  Abs(Log(ThesisRec. ACTEFFORT)  •  LogEstEffort) 

•Calculate  suns 

SSE  3  SSE  «  MRE  '  2 

LogSSE  3  LogSSE  +  LogMRE  '  2 

LogSSTO  3  LogSSTO  (Log(ThesisRec.ACTEFFORT)  -  LogActEffMean)  ‘  2 
SunMRE  3  SunMRE  *  MRE 

If  MRE  /  ThesisRec.ACTEFFORT  <3  MRELimit  Then 
PredLevel  =  PredLevel  ♦  1# 

End  If 

If  MRE  <  Abs(ThesisRec. ACTEFFORT  -  (ThesisRec. PI  *  BaseCoeff icient  • 

(ThesisRec. ACTKDSI  ‘  BaseExponent )  *  (ThesisRec. EDSI  /  ThesisRec. ACTKDSI )))  Then 
ImproveLevel  3  ImproveLevel  1# 

End  if 
End  If 

more  3  AgiViewNext(ThesisHandle) 

Loop 

•AgiViewClose  BoehmHandle 
If  CategoryCount  >  0  Then 

R2  3  1  •  (LogSSE  *  (CategoryCount  '  1))  /  (LogSSTO  *  (CategoryCount  -  2)) 

RRMS  3  (Sqr(SSE  /  CategoryCount))  /  ActEffMean 
MREMean  3  SunMRE  /  CategoryCount 
PredLevel  3  (PredLevel  /  CategoryCount)  *  100 
ImproveLevel  3  (ImproveLevel  /  CategoryCount)  •  100 
End  If 

Texts. Text  3  Format$(R2,  ••0.0000") 

TextA.Text  3  Format$(RRMS,  ••O.OOO") 
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Texts. Text  »  FanMt$(MREMean,  "0.00") 

Tcxt6.Text  •  FormatSCPredLevel,  "#0.0")  ♦  "X" 
Text9.Text  »  FormatSdmproveLevel,  "#0.0")  ♦  "X" 
End  Sub 

Sub  ciiKlCancel_Ctick  (} 

Unload  frmThesStat 
End  Sub 
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Code  for  ThesTabl  Form 


Option  Explicit 

Sub  cffldCancel_Click  (} 
Unload  frmThesTable 
End  Sub 


Code  for  ThesYAxs  Form 

Option  Explicit 

Sub  cmdCancel_Cl ick  () 

Unload  frmYAxis 
End  Sub 

Sub  cmdOK_Click  O 

NormState  «  Norm_Off 
frmThesGraphlcmdNorffl. Enabled  3  False 
If  optEXTINE. Value  *  True  Then 
YPick  ■  Executable  Time 
frmThesGraphlGraphT.LeftTitle  >  “EXTINE" 
Elself  optTimeUtil. Value  ■  True  Then 
YPick  >  Time_Util 

frmThesGraphlGraphl.LeftTitle  3  "Time  X" 
Elself  optStor .Value  -  True  Then 
YPick  *  Storage 

frmThesGraphlGraphl.LeftTitle  =  "STOA" 

Elself  optNeskJti  I  .Value  "  True  Then 
YPick  *  Mem  Util 

frmThesGrapiilGraphl.LeftTitle  3  "Mem  X" 
Elself  optPi. Value  3  True  Then 
YPick  3  Pi_Mult 

frmThesGra^lGraphl.LeftTitle  3  ••p|u 
Elself  optAexp. Value  3  True  Then 
YPick  3  Analyst_Experience 
frmThesGraphlGraphl.LeftTitle  3  "AEXP" 

Elself  optLexp. Value  3  True  Then 
YPick  3  Lang_Experience 
frmThesGraphlGraphl.LeftTitle  =  "LEXP" 

Elself  opt ActKOSl. Value  3  True  Then 
YPick  3  Actual_ICDSI 

frmThesGraphlGraphl.LeftTitle  =  "Actual  KOSI" 
Elself  optEOSl .Value  3  True  Then 
YPick  3  Equivalent  OSI 

frmThesGraphlGraphl.LeftTitle  *  "Equiv  KDSI" 
Elself  optActEf fort .Value  »  True  Then 
frmThesGraph I cffldNorm. Enabled  3  True 
YPick  3  Actual_Effort 
frmThesGraphlGraphl.LeftTitle  =  "MM" 

End  If 

Unload  frmYAxis 
End  Sub 

Sub  Form_Load  () 

Select  Case  YPick 

Case  Executable  Time 

optEXTINE. Value  =  True 
Case  Time_Util 

optTimeUtil. Value  =  True 
Case  Storage 

optStor. Value  -  True 
Case  Meffl_Util 

optMemUtil. Value  -  True 
Case  Pi_Hult 

optPi. Value  3  True 
Case  Analyst_Experience 
optAexp.Value  3  True 
Case  Lang_Experience 
optLexp. Value  3  True 
Case  Actual  KOSI 

optActKDSI .Value  3  True 
Case  Equivalent_OSI 

optEDSI .Value  3  True 
Case  Actual  Effort 

optActETfort. Value  =  True 
End  Select 
End  Sub 
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Code  for  ThsCretC  Fom 


Option  Explicit 

Dim  ThesisFi leSpec  As  String 

Sub  cmdCancel_Cliclc  () 

■cmdClear'Click 

Unload  frmThsCreate  'Close  SampleHandle  is  in  Unload 
End  Sub 


Sub  cffidClear  Click  () 

While  AgTvieMFirst(ThesisHandle) 

AgiViewOelete  ThesisHandle 
If  AgiErrorO  <>  0  Then 

MsgBox  "Record  deletion  error:  "  *  AgiErrorTextO 
End  If 

Wend 

cmdCreate. Enabled  >  True 
cmdC I ear. Enabled  >  False 
cmdSave. Enabled  *  False 
End  Sub 


Sub  cindCreate_Click  O 
Dim  NumBC~ 

Dim  NunRec 
Dial  EffSOPercent 
Dim  SO 
Dim  EAF 
Dim  EstEffort 
Dim  PrevBC 
Dim  LearnEffect 
■Dim  EstEffort 


As  Integer 
As  Integer 
As  Single 
As  Single 
As  Double 
As  Single 
As  ThesisType 
As  Double 
As  Single 


Randoaiixe  'Reseeds  random  number  generator 

SO  3  Val(txtFactorSO.Text) 


cffldClear_Click  'Clear  existing  records  if  any 

'Create  record  from  Development  Data 
ThesisRec. SCRUM  «  1 
If  optCIO. Value  "  True  Then 
ThesisRec. Category  =  "CIO" 

Elself  optNAV. Value  s  True  Then 
ThesisRec. Category  s  "NAV" 

Elself  optCAV. Value  *  True  Then 
ThesisRec. Category  =  "CAV" 

Elself  optECS. Value  «  True  Then 
ThesisRec. Category  *  "ECS" 

Elself  optOFF. Value  *  True  Then 
ThesisRec. Category  »  "OFF" 

End  If 

ThesisRec. RELY  >  NDEVd,  SO) 

ThesisRec.OBSIZE  =  NDEVd,  SO) 

ThesisRec.CPLX  >  NDEVd,  SO) 

ThesisRec.TINEUTlL  "  Val(txtDevTime.Text) 

ThesisRec. EXT  I ME  3  FindEXTIME(Val(ThesisRec.TIMEUTIL)) 

ThesisRec.MEMUTIL  3  Val(txtOevMem.Text) 

ThesisRec.STOR  3  FindSTOR(Val(ThesisRec.MEMUTIL)) 

ThesisRec. VIRT  3  NDEVd,  SO) 

ThesisRec. TURN  >  NDEVd,  SO) 

ThesisRec.ACAP  3  NOEVd,  SO) 

ThesisRec. AEXP  3  NOEVd,  SO) 

ThesisRec.PCAP  3  NOEVd,  SO) 

ThesisRec.VEXP  «  NOEVd,  SO) 

ThesisRec.LEXP  3  tWEVd,  SO) 

ThesisRec.MOOP  3  NDEVd,  SO) 

ThesisRec. TOOL  >  NDEVd,  SO) 

ThesisRec.SCEO  3  NOEVd,  SO) 

ThesisRec.RVOL  3  NOEVd,  SO) 

EAF  3  ThesisRec. RELY  *  ThesisRec.OBSIZE  *  ThesisRec.CPLX  *  ThesisRec. EXT I ME 
EAF  3  EAF  *  ThesisRec.STOR  •  ThesisRec.vIRT  •  ThesisRec. TURN  *  ThesisRec.ACAP 

EAF  3  EAF  *  ThesisRec.AEXP  *  ThesisRec.PCAP  •  ThesisRec.VEXP  *  ThesisRec.LEXP 

EAF  3  EAF  "  ThesisRec.MOOP  *  ThesisRec. TOOL  *  ThesisRec.SCEO  *  ThesisRec.RVOL 

ThesisRec. PI  3  eaf 
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ThcsisRtc. ENTROPY  «  1« 

ThesisRcc.ACTKOSl  >  VaKtxtOevKDSl .Text) 

ThestsRec.AOOKDSI  «  ThesisRec.ACTKDSl  *  (VaKtxtPerAdd.Text)  /  100)  *  NOEVd. 
VaKtxtPerSO.Text)  /  100) 

ThasisRec.NOOKOSl  >  ThesisRec.ACTKDSl  *  (VaUtxtPerNod.Text)  /  100)  *  NOEVd, 
Val(txtPerSO.Text)  /  100) 

ThesisRec.DELKDSI  >  ThesisRec.ACTKDSl  *  (VaUtxtPerOel .Text)  /  100)  *  NOEVd, 
VaKtxtPerSO.Text)  /  100) 

ThesisRec.EOSI  «  FindEOSKVaKThesisRec.AOOKDSI),  VaKThesisRec.NOOKDSt ), 
VaUThesisRec.OELKOSI)) 

EstEffort  ■  EAF  *  VaKtxtCoeff icient.Text)  *  (ThesisRec.ACTKDSl  '  Val(txtExponent.Text))  * 
(ThesisRec.EDSI  /  ThesisRec.ACTKDSl) 

'EffSOPercent  is  the  X  of  SO  at  the  EOSl  value 
EffSOPercent  *  VaKtxtEffortSO.Text)  /  ThesisRec.EDSI 

ThesisRec. ACTE F FORT  «  Exp(Log(EstEf fort)  ♦  W)EV(0,  Logd  *  EffSOPercent))) 

AgiViewAdd  ThesisHandle,  ThesisROS,  ThesisRec 
If  AgiErrorO  <>  0  Then 

MsgBox  "Could  not  create  first  record." 

cflidClear_Click 

Exit  Sub” 

End  If 

'Create  Time  series  records  for  remaining  block  changes 
PrevBC  >  ThesisRec  'Hold  prior  years  data 
Screen. HousePointer  s  HourGlass 
For  NumRec  >  2  To  IntCVaKtxtBCNun.Text)) 

ThesisRec  »  PrevBC  'Intialize  this  block  change  data 
ThesisRec.BCNUM  a  NumRec 
If  PrevBC. TIMEUTIL  <  9S«  Then 

■Increase  at  KOSI  growth  rate 

ThesisRec. TIMEUTIL  >  PrevBC. TIMEUTIL  *  (1#  *  ((PrevBC. AODKOSI  -  PrevBC. DELKDSI )  / 
PrevBC.ACTKDSD) 

Else 

'Increase  half  remaining 

ThesisRec. TIMEUTIL  =  PrevBC. TIMEUTIL  ♦  (.5  •  (100#  -  PrevBC.TIMEUTID) 

End  If 

If  ThesisRec. TIMEUTIL  >  100#  Then 

MsgBox  "The  Throughput  growth  has  exceed  100X  capacity"  nlO  ^  "in  block  change  ''  * 
Str(MumRec)  *  ".« 

Exit  For 
End  If 

ThesisRec. EXTIME  *  FindEXTIME(Val(ThesisRec. TIMEUTIL)) 

If  PrevBC. MEMUT I L  <  95#  Then 

'Increase  at  KOSI  growth  rate 

ThesisRec. MEMUTIL  =  PrevBC. MEMUT I L  *  (1#  ♦  ( (PrevBC. ADOKDSI  •  PrevBC.OELKDSI )  / 
PrevBC.ACTKDSD) 

Else 

'Increase  half  remaining 

ThesisRec. MEMUTIL  =  PrevBC. MEMUTIL  ♦  (.5  •  (100#  •  PrevBC. MEMUTIL))  'add  half 

remaining 

End  If 

If  ThesisRec. MEMUTIL  >  100#  Then 

MsgBox  "The  memory  growth  has  exceed  lOOX  capacity"  ♦  NLO  ♦  "in  block  change  "  ♦ 
Str(NijnRec)  ♦ 

Exit  For 
End  If 

ThesisRec.STOR  =  FindSTOR(Val(ThesisRec.MEMUTIL)) 

LearnEffect  *  FindLearn(Int(ThesisRec.BCNUM)) 

'Spread  Learning  Effect  to  AEXP  and  LEXP 
ThesisRec.AEXP  »  PrevBC. AEXP  *  Sqr(LearnEffect) 

ThesisRec. LEXP  ^  PrevBC.LEXP  *  Spr(LearnEffect) 

EAF  3  ThesisRec. RELY  *  ThesisRec. OBSIZE  *  ThesisRec. CPLX  *  ThesisRec. EXT  I ME 
EAF  =  EAF  •  ThesisRec.STOR  *  ThesisRec. VIRT  •  ThesisRec. TURN  •  ThesisRec. ACAP 

EAF  »  EAF  *  ThesisRec.AEXP  *  ThesisRec. PCAP  *  ThesisRec.VEXP  •  ThesisRec. LEXP 

EAF  s  EAF  *  ThesisRec. MOOP  •  ThesisRec. TOOL  *  ThesisRec. SCED  *  ThesisRec. RVOL 

ThesisRec. PI  *  EAF 

ThesisRec.ACTKDSl  -  PrevBC. ACTKDSI  *  PrevBC. AODKOSI  -  PrevBC.OELKDSI 
ThesisRec. ADDKDSI  ThesisRec.ACTKDSl  *  (Val(txtPerAdd.Text)  /  100)  •  NOEVd, 
Val(txtPerSO.Text)  /  100) 

ThesisRec.MOOKOSI  >  ThesisRec.ACTKDSl  *  (VaUtxtPerMod.Text)  /  100)  •  NDEV(1, 
Val(txtPerSO.Text)  /  100) 

ThesisRec.DELKDSI  »  ThesisRec.ACTKDSl  •  (VaUtxtPerOel. Text)  /  100)  •  W)EV(1, 
Val(txtPerSO.Text)  /  100) 
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ThMisRtc.EDSI  *  FindEDSKVaUThestsRec.AOOKOSI),  VaUThesisRec.MOOKDSl ), 

Va I ( Thes i sRec . DELKOS I ) ) 

EstEffort  *  EAF  *  VaKtxtCocff ictent.Text)  *  (ThesisRec.ACTKOSl  *  Val(txtExponent.Text))  * 
( Thes isRec. EDS 1  /  ThesisRec.ACTKOSl) 

■EffSOPercent  is  the  X  of  SO  at  the  EDSI  value 
EffSOPercent  »  Val(txtEffortSO.Text)  /  Thes isRec. EDSI 

ThesisRec.ACTEFFORT  «  Exp(Log(EstEffort)  «  NOEV(0,  Log(1  *  EffSOPercent))) 

AgiViewAdd  ThesisHandle,  ThesisROS,  ThesisRec 
If  AgiErrorO  <>  0  Then 

HsgBox  "File  Error:  Could  not  add  block  change  "  +  Str(NtnRec)  * 

ciiidClear_Click 

Exit  Sub” 

End  If 

PrevSC  ■  ThesisRec  'Hold  previous  block  change  data 
Next  NunRec 

ciadCreate. Enabled  a  False 
aadClear. Enabled  >  True 
cariSave. Enabled  >  True 
Screen. MousePointer  a  Default 
End  Sub 

Sub  cffldSave_Click  () 

Dim  SaveHandle  As  Integer 
Dim  Filetitle  As  String 

■Get  new  FileSpec 
On  Error  Resuna  Next 
CMDialogl.OefaultExt  >  "AGI" 

CMOialogl. Flags  >  OFN  PATHMUSTEXIST  ♦  OFN  OVERWRITEPROMPT  ♦  OFN  HIDEREADONLY 
OFN  EXTENSIONOIFFERENT 

“CHOialogl. Action  *  0LG_FILE_SAVE 
If  Err  a  32755  Then  'user  selcted  cancel  button 

Exit  Sub 
End  If 

On  Error  GoTo  0 

Debug. Print  "Save  Filetitle  is  "  ♦  CHOialogl. Fi letitle  ♦ 

■Test  to  see  if  new  file  is  already  open  or  exists 
Sc reen.HousePo inter  •  HourGlass 

If  CHOialogl. Filetitle  «  fmMainlCHOialogl. Filetitle  Then 
AgiVieuClose  OBHandle  'Close  Open  Copy 

Kill  CHOialogl. Filenaaie  'Delete  Previous  open  copy 

frsMainimnuCloseOB. Enabled  a  False  'Reset  menu  selection 
fmMainlmnuVieNGraph. Enabled  a  False 
fmMainimnuVieMTsble. Enabled  a  False 
frnHainlmnuVieMOata. Visible  a  False 
fmMainlmnuCalBoehm. Enabled  a  False 
frnMainlnruStatEval. Enabled  a  False 
Elself  CHOialogl. Filetitle  a  "THSFILE.AGI"  Then 

Exit  Sub  'File  update  Mill  be  automatic  upon  Cancel_Click 

Elself  DirSCCHOialogI .Filerwme)  <>  ""  Then  'If  Fite  exists  ” 

Kill  CHOialogl. Filenaew  'Delete  unopenr  '  coy 

End  If 

'  Open  blank  file  to  copy  into 
SaveHandle  a  AgiFreeFileO 
Filetitle  a  CHOialogl .Fi letitle 
AgiViewOpen  SaveHandle,  Filetitle,  "CAUR" 

If  AgiErrorO  <>  0  Then 

HsgBox  "File  Creation  Error:  "  *  AgiErrorTextO 
End  If 

'  Copy  current  file  into  blank  copy  for  saving 
more  a  AgiViewFirstlThesisHandle) 

While  more 

AgiVieuGet  ThesisHandle,  ThesisROS,  ThesisRec 
AgiVieuAdd  SaveHandle,  ThesisROS,  ThesisRec 
If  AgiErrorO  <>  0  Then 

HsgBox  "Error  adding  record  to  save  file."  ♦  NLO  ♦  "File  results  undetermined." 
AgiVieuClose  (SaveHandle) 

Screen. HousePointer  a  Default 
Exit  Sub 
End  If 

more  a  AgiVieMNext(ThesisHandle) 
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■SMUpleHandl*  is  remains  open 


AgiVieMClose  (SaveHandle) 

Screen. NouscPointer  «  Default 
End  Sub 

Function  FindEOSl  (AOOKDSI  As  Doti)le,  mKDSI  As  Double.  DELKOSI  As  Double)  As  Double 
■Solution  is  found  by  weighting  the  KOSt  values 
•These  weightings  are  from  the  Softcost-R  Manual  page  R-83 
■Note  the  wieghtings  for  lines  and  modules  have  been  added  so  as  to  include 
•the  effect  of  altering  both  the  line  and  the  module 
FindEDSI  »  .53  *  AOhKDSI  ♦  (.27  ♦  .24)  •  MOOKDSI  ♦  (.15  ♦  .11)  *  DELKDSI 
End  Function 

Function  FindEXTINE  (PerTime  As  Double)  As  Double 
If  PerTime  <■  65#  Then 
FindEXTIME  «  1# 

Else 

FindEXTIME  »  1.82  *  (PerTime  /  100#)  ‘  1.305 
End  If 

End  Function 

Function  Fin(#.earn  (BCNUH  As  Integer)  As  Double 

•This  function  assunes  the  realtionship  holds  true  for  6  block  changes. 

■But  SYSCON  states  relationship  holds  for  6  years. 

■Future  may  need  to  adjust  for  years  if  block  changes  are  not  1  year 
•The  exponent  comes  from  SYSCON.  Thesis  TAble  5 
If  BCNUM  »  2  And  BCNUM  <»  6  Then 

•Mo  coefficient  =>  normalize  to  1.0 

■Note  Effect  is  ratio  to  previous  BC  and  not  the  first  BC 
FindLearn  «  (BCNUM  *  (-.375))  /  ((BCNUM  -  1)  ‘  (-.375)) 

Else 

FindLearn  *  1# 

End  If 

End  Function 

Function  FindSTOR  (PerMem  As  Double)  As  Double 
If  PerMem  <»  65#  Then 
FindSTOR  «  1# 

Else 

FindSTOR  »  1.94  •  (PerMem  /  100#)  *  1.425 
End  If 

End  Function 

Sub  Form  Load  (} 

Dim  Filetitle  As  String 
Dim  FileSpec  As  String 

•Open  new  file  (agi  formats  only). 

ThesisNandle  =  AgiFreeFi  leO 
Filetitle  =  ••THSFILE.AGP^ 

AgiViewOpen  ThesisHandle.  Filetitle,  '•CAUR^^ 

If  Agi Error! )  <>  0  Then 

MsgBox  ■•File  Open  Error;  ••  ♦  AgiErrorTextO 
End  If 

Tablel.ViewHandle  «  ThesisHandle 

•Enable  Appropriate  Buttons 
more  =  AgiViewFirstlThesisHandle) 

If  more  Then 

cmdCreate. Enabled  =  False 

Else 

cmdClear. Enabled  a  False 
cmdSave. Enabled  -  False 
End  If 

•Set  FileSpec  for  Save  Dialog  Box 
If  Right(Fi lei. Path,  1)  <>  ■■\^'  Then 

FileSpec  »  Filel.Path  ♦  ■•\"  ♦  Filetitle 

Else 

FileSpec  »  Filel.Path  ♦  Filetitle 
End  If 

CMOialogl. Filename  =  FileSpec 
End  Sub 
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Sub  Form  Unload  (Cancel  As  Integer) 

AgivIewClose  ThesisHandle 
End  Sub 

Sub  txtBCNue  LostFocus  O 
Din  BCNUii  As  Integer 
BCHUM  «  Int(Val(txtBCNun.Text)} 

If  BCMUN  >  0  Then 

txtBCNue. Text  «  Str(BCNUM) 

Else 

ErrMsg  >  "Please  select  a  positve  value  for"  *  NLO 
ErrMsg  >  ErrMsg  *  "the  nuaber  of  records." 

NsgBox  ErrMsg 
txtBCNue.Text  ■  "10" 
txtBCNue.  Set  Focus 
End  If 
End  Sub 
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Cod*  for  ThsCrapft  Form 

Option  Explicit 

Sub  cndCancel.Click  () 

Graph1.0ataR«8*t  *  G_AU_0ata 
Unload  fnaThosGraph 
End  Sub 

Sub  caaMona_Click  () 

If  NoraStat*  *  Norai_Off  Then 

caRMona.Caption~«  "Nonaalize  Off" 

NonaStat*  «  Nona.On 

Elsa 

catdNona. Caption  *  "Noraaliza  On" 

NonaStat*  •  Nona  Off 
End  If 

YPick  »  Actual_Effort 
LoadTh*sisOata~NonaState,  YPick 

Graphl .OrawMod*  *  G_0rau 
If  FileGraph  3  1  Then 

Graphl .DrauMod*  *  G  Write 
End  If 
End  Sub 

Sub  csKlYAxis_Click  <) 
fmiYAxisTshow  Modal 

LoadThesisOata  NomState,  YPick 

Graphl.OrawHode  3  G_0raw 
If  FileGraph  3  1  Then 

Graph I.OrawMode  3  g  Write 
End  If 
End  Sub 

Sub  formJLoad  () 

txtOBNaiae.Text  3  OBFileSpec 

■set  filename  for  saving  graph 
Graphl. ImageFile  3  "thesgrph* 

Screen. MousePointer  3  HourGlass 
WindowState  3  Maximized 
NormState  3  Norm  Off 

Graphl. LeftTitle~3  hhm" 

Graphl. BottomTitle  3  "Block  Change  Nuiber" 

Graphl .OrauMode  -  G_0rau 

YPick  3  Actual_Effort 
LoadThesisOata~NormState,  YPick 
Screen. MousePointer  3  HourGlass 

Graphl .OrauMode  3  G_0raw 
If  FileGraph  3  1  Then 

Graphl. OrauMode  3  g  Write 
End  If 

If  FileGraph  3  1  Then 

Graphl. OrauMode  3  g  Write 
End  If 

Screen. MousePointer  3  Default 
End  Sub 

Sub  LoadThesisOata  (Normalize  As  Integer,  YChoice  As  Integer) 

Oim  account  As  Integer 

Graphl. NunPoints  3  AgiVieuCountCOBHandle) 

Graphl. IndexStyle  3  1  'Enhanced  index  style  permits  access  to 
'arrays  for  holding  data. 

■Set  mode  characteristics 
Graph I.ThisSet  3  1 
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Graphl .ThisPoint  >  1 

■Array  subscripting 
•  1  >  CosN  /  ID 

'  2  >  Navigation  Sensors 

'  3  s  Core  Avionics 

'  4  *  Electronic  Combat  Systems 

'  5  >  Offensive  Sensors 

more  >  AgiViewFirst(DBHsndle) 

If  store  Then 

AgiViewGet  DBHandle,  ThesisROS,  ThesisRec 
Select  Case  TrisKThesisRec. Category) 

Case  "CIO" 

Graph 1. Legend! ext  >  "C/IO" 

Graphl.SyisbolOata  >  G_CROSS_PLUS 
Graph!. ColorOata  >  G  IlUE  ~ 

Case  "MAV" 

Graph!. LegendText  >  "NAV" 

Graph!. SysbolOata  a  G  CROSS  TIMES 
Graph!. ColorOata  =  G  GREEN  ~ 

Case  “CAV  ~ 

Graph!. Legend! ext  =  "CORE" 

Graph!. SymbolOata  ^  G_TRIANGLE_UP 
Graph!. ColorOata  =  G  RED 
Case  "ECS" 

Graph!. Legend! ext  >  "E  C" 

Graph!. SymbolOata  >  G_DIAHONO 
Graph!. ColorOata  a  g  BLACK 
Case  "OFF" 

Graph!. Legend! ext  «  “OFF" 

Graph!. SysRmlData  >  G_SaUARE 
Graph!. ColorOata  -  G_BROUN 
End  Select  ~ 

End  If 

■Load  the  data  to  the  graph 
BCCount  3  0 

more  -  AgiViewFirst(DBHandle) 

Screen. MousePointer  «  HourGlass 
Oo  While  more 

AgiViewGet  DBHandle,  ThesisRDS,  ThesisRec 
BCCount  «  BCCount  >  ! 

Graph!. ThisPoint  =  BCCount 
Graph! .XPosOata  *  BCCount 
If  Norswlize  Then 

' Graph!. GraphOata  =  ThesisRec. ACTEFFORT  /  ThesisRec. PI 
■Note  below  use  default  coefficient  and  exponent 

Graph! .GraphOata  =  ThesisRec. PI  *  2.85  *  (ThesisRec. ACTKOSI  '  !.1S}  *  (ThesisRec. EDS I 
/  ThesisRec.ACTKDSI) 

Else 

Select  Case  YChoice 

Case  Executable_Time 

Graph!. GraphOata  »  ThesisRec. EXTIME 
Case  Time  Util 

GraphT. GraphOata  =  ThesisRec. TIMEUTIL 
Case  Storage 

Graph!. GraphOata  =  ThesisRec.STOR 
Case  Mem_Util 

Graph! .GraphOata  s  ThesisRec.MEMUTIL 
Case  Pi_Mult 

Gra^!. GraphOata  >  ThesisRec. PI 
Case  Analyst_Experience 

Graph! .GraphOata  »  ThesisRec. AEXP 
Case  Lang  Experience 

GraphT. GraphOata  a  ThesisRec.LEXP 
Case  Actual_KDSI 

Graph!. GraphOata  =  ThesisRec.ACTKDSI 
Case  Equivalent_DSI 

Graph!. GraphOata  »  ThesisRec. EDS I 
Case  Actual_Effort 

Graph!. GraphOata  3  ThesisRec. ACTEFFORT 
End  Select 
End  If 

■Debug. Print  Si.r(Graph!. GraphOata) 
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more  >  AgiVieMNext(OBHandle) 
Loop 

Sc roon.MousePo inter  ■  Default 
End  Sub  • 


Cod*  for  ZooaOata  Form 


Option  Explicit 
Dim  TampYMax  As  Single 
Dim  TempYNin  As  Single 
Dim  TempXMax  As  Single 
Dim  TempXMin  As  Single 

Sub  cmdCancel_Click  O 
Unload  frmZooaOata 
End  Sub 

Sub  cffldOK_Click  () 

YMax  «  Val(txtYNax.Text) 

YMin  a  Val(txtYMin.Text) 

XMax  a  Val(txtXMax.Text) 

XMin  a  Val(txtXMin.Text) 

Unload  frmZooaOata 
End  Sub 

Sub  cmdReset_Click  () 

txtYMax.Text  a  strlTempYHax) 
txtYMin.Text  =  str(TeapYHin) 
txtXMax.Text  =  Str(TeaipXMax) 
txtXMin.Text  *  Str(TempXMin) 

txtYMax.SetFocus 
End  Sub 

Sub  Form_Load  O 

txtYMax.Text  =  Str(YMax) 
txtYMin.Text  =  Str(YMin) 
txtXMax.Text  a  Str(XMax) 
txtXMin.Text  =  Str(XMin) 

TempYMax  a  YMax 
TempYMin  =  YMin 
TeoipXMax  a  XMax 
TempXMin  >  xMin 
End  Sub 
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Object  Oriented  Design  Models 

Data  Dictionary 


Data  Dictinnary  F.ntrv  Format  and  D^finitinns 


Entity  Label  :=  Elntity  Role;  D^inition 
where 

Entity  Label  is  the  name  of  the  entity  appearing  in  the 
diagram. 

is  "defined  as" 

Entity  Role  is  the  role  the  entity  plays  in  the  diagram. 

Roles  are  either 

Objects,  Processes,  Attributes,  Data,  or  Relationships. 
Definition  is  the  definition  of  the  entity  within  the  context 
of  the  model. 

a)  Objects  are  physical  or  abstract  actors  that  have  meaning  in 
the  problem  space. 

b)  Objects  are  characterized  by  Attributes  and  are  linked  together 
by  Relationships. 

c)  Attributes  are  features  of  an  Object  that  have  meaning  in  the 
problem  space  and  need  to  be  maintained  in  the  model  space. 

d)  Relationships  describe  how  one  Object  interacts  with  another. 

e)  Data  is  information  used  or  created  by  a  Process. 


A  Dproved  ECP  ;=  Object:  Engineering  Change  Proposal  that  has  been  reviewed  and 
approved  by  the  Configuration  Control  Board  and  is  to  be  included  in  the  current 
block  change  cycle 

A  vvroves  ;=  Relationship:  "the  CCB  approves  the  ECP" 

A  vailabiliiv  :=  Attribute:  describes  how  much  time  computer  assets  owned  by  the 
SSA  can  be  used  during  the  development  phase  of  the  current  block  change  cycle 

Block  Change  :=  Object:  ail  materials  produced  by  the  SSA  during  the  block  change 
process  that  are  released  to  the  field 
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CCB  :=  Object;  formal  group  (Configuration  Control  Board)  comprised  of  User 
personnel  and  SSA  personnel  responsible  for  reviewing  and  approving  all  changes  to 
be  made  to  the  Product  Baseline  during  the  current  block  change  cycle 

CCB  Process  :=  Process:  actions  taken  by  the  CCB  to  review  and  approve  an  ECP 
for  inclusion  in  the  current  block  change 

Change/ Problem  Report  :=  Object:  standard  forms  that  describe,  in  terms  of 
requirements,  what  needs  to  be  added,  deleted,  or  modified  in  the  Product  Baseline 

Chanse  Requests  ;=  Data;  standard  form  that  describes,  in  terms  of  requirements, 
what  needs  to  be  added,  deleted,  or  modified  in  the  Product  Baseline 

Code  :=  Object:  the  executable  component  of  Software 

Complexity  :=  Attribute:  describes  the  design/structure  of  the  including  the 
completeness  and  readability  of  the  available  documentation,  readability  of  the 
available  code  listings,  and  the  degree  of  coupling  and  cohesion  within  the  Code 
itself 

Cost  ;=  Attribute:  estimate  in  dollars  of  the  Resources  needed  to  complete  the  ECP 

Data  Size  ;=  Attribute:  size  of  the  database/data  structures  required  by  the  Code  to 
perform  it's  function  according  to  the  Requirements 

Demonstrates  Relationship;  "the  Test  Plan  demonstrates  the  Block  Change  (meets 
the  user's  requirements)" 

Depot  MX  :=  Object:  Depot  maintenance  Manuals  for  the  weapon  system 

Description  :=  Attribute:  the  portion  of  the  Change  Problem  Report  that  describes 
what  is  wrong  or  what  needs  to  be  done  to  the  software  which  forms  the  requirement 
for  the  next  block  change  cycle 

Design  Docs  ;=  Object,  documents  (generally  delivered  with  the  software)  that 
describe  the  software  design  at  various  levels  of  abstraction 

Develop  Changes  ;=  Process:  translation  by  the  SSA  of  the  approved  ECP  into 
executable  software  for  Ground  Integration  Test 

Development  Paradigm  ;=  Attribute:  the  specific  engineering  management  method 
used  to  plan  and  track  the  Develop  Changes  process 

Draft  ECP  :=  Data;  ECP  prior  to  approval  by  the  CCB 


D.4 


ECP  ■=  Object:  collection  of  one  or  more  Change  Pmblem  Reports  that  have  been 
approved  for  inclusion  into  the  Product  Baseline  during  the  next  block  change  cycle 

Efficiency  ;=  Attribute;  the  average  SSA  manhours  of  effort  it  takes  to  change  a 
single  line  of  code  measured  from  the  Effort  Estimation  process  to  the  delivery  of  a 
test  tape  to  the  Ground  Integration  Test  process 

Equipment  :=  Object:  Computer  hardware,  software,  and  tool  sets  owned  by  the 
SSA  that  can  be  applied  to  the  current  block  change  cycle 

Estimate  Effort  :=  Process;  comprises  investigating,  prioritizing,  and  estimating  the 
effort  required  to  implement  each  Problem  Report  and  Change  Request  waiting  to  be 
implemented  in  the  current  block  change  cycle 

Effort  Estimate  :=  Data;  documented  result  of  the  Effort  Estimate  process 

Experience  :=  Attribute;  describes  SSA  programmer  and  analyst  personnel 
experience  with  the  software  being  modified  and  with  the  SSA  Equipment 

Field  Change  ;=  Process:  distributing  the  Updated  Tapes  &Manuals  to  the  User 

Field  MX  ;=  Object:  current  configuration  manuals  used  by  the  Field  MX  Personnel 

Field  MX  Personnel  :=  Object;  weapon  system  maintainers  that  are  assigned  to  the 
weapon  system's  base  of  operations 

Fielded  to  :=  Relationship;  "the  Block  Change  is  fielded  to  the  Usei^' 

Fliers  :=  Object:  weapon  system  operators 

Flizht  Crew  :=  Object:  current  configuration  manuals  used  by  Fliers 

Flisht  Failed  Tape  :=  Data:  Software  with  major  problems  that  were  uncovered 
during  Flight  Test  requiring  Rework 

Flisht  Problems  Not  Waivered  :=  Data:  Software  with  minor  problems  uncovered 
during  Flight  Test  that  requires  Rework 

Flisht  Test  ;=  Process;  software  testing  that  occurs  on  one  or  more  test  aircraft  in 
support  of  development  testing  or  operational  testing 

Flisht  Test  Equipment  :=  Object:  the  aircraft  to  be  used  during  Flight  Test 

Flisht  Test  Plan  :=  Object:  documentation  that  describes  the  objectives  of  the  Flight 
Test  process  in  terms  of  Flight  Test  Procedures,  Equipment,  and  Results 
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Flieht  Test  Procedures  :=  Object;  documentation  describing  the  mission  profiles,  and 
series  of  actions  to  be  used  during  the  Flight  Test  process 

Flieht  Test  Results  :=  Object;  documentation  describing  the  outcome  of  die  Flight 
Test  process 

FT  Schedule  ;=  Attribute;  description  of  the  availability  of  Flight  Test  Equipment 

Ground  Inteemtion  Test  :=  Process;  software  ground  testing  done  in  the  avionics 
system  integration  facility  or  other  system  mockup 

Ground  Test  Equipment  ;=  Object;  hardware  and  facilities  used  during  Ground 
Integrcaion  Test 

Ground  Test  Plan  ;=  Object;  documentation  describing  the  objectives  of  the  Ground 
Integration  Test  process  in  terms  of  procedures,  equipment,  and  results 

Ground  Failed  Tape  ;=  Data;  software  with  major  problems  that  were  uncovered 
during  Ground  Integration  Test  requiring  Rework 

GT  Speed  ;=  Attribute;  description  of  the  speed  of  the  host  computer  used  during 
Ground  Integration  Testing 

GT  Memory  ;=  Attribute:  description  of  the  amount  of  unused  memory  in  the  host 
computer  used  during  Ground  Integrcaion  Testing 

GT  Procedures  ;=  Object:  documentation  describing  the  series  of  actions  to  be 
accomplished  during  the  Ground  Integration  Test  process 

GT  Results  :=  Object:  documentation  describing  the  outcome  of  the  Ground 
Integration  Test  process 

Integrated  Waivered  Tape  :=  Data:  Software  with  minor  problems  discovered  during 
the  Ground  Integration  Test  process  that  is  being  released  to  the  Flight  Test  process 

Integrated  Tape  :-  Data:  Software  with  no  problems  discovered  during  the  Ground 
Integration  Test  process  that  is  being  released  to  the  Flight  Test  process 

Integrcaion  Problems  Not  IV covered  :=  Data:  Software  with  minor  problems 
discovered  during  the  Ground  Integration  Test  process  that  requires  Rework 

Local  Policy  :=  Object:  documentation  that  describes  the  SSA  software  Development 
Paradigm,  and  Standards 
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Manuals  :=  Object:  family  of  documents  describing  the  weapon  system  operation  and 
maintenance  practices  and  procedures 

Memory  .=  Attribute:  description  of  the  unused  portion  of  the  Target  Computer  RAM 
and  ROM 

Minor  Flight  Problems  :=  Data:  Software  with  minor  problems  uncovered  during  the 
Flight  Test  process 

Minor  Inteeration  Problems  :=  Data:  Software  with  minor  problems  uncovered  during 
the  Ground  Integration  Test  process 

Operational  Tape  :=  Data:  current  weapon  system  Software  and  supporting  Manuals 
Personnel  :=  Object:  people  employed  by  the  SSA 

Prioritize  Board  :=  Process:  rank  ordering  of  changes  to  be  made  to  the  Software  and 
preparation  of  an  ECP  for  those  changes 

Priority  :=  Attribute:  describes  the  urgency  of  the  Change/ Problem  Report 

Problem  Reports  :=  Data:  description  of  problems  or  errors  in  the  current  Product 
Baseline  that  must  be  corrected  through  additions,  deletions,  or  modifications 

Procedures  :=  Object:  all  previous  documented  test  actions  dating  from  development 
to  the  current  block  change  cycle 

Produces  :=  Relationship:  "the  SSA  produces  the  Block  Change" 

Product  Baseline  :=  Object:  documentation  that  describes  the  configuration  of 
Software,  Manuals,  and  Tests  that  exist  at  the  start  of  a  block  change  cycle 

Reliability  :=  Attribute:  describes  the  required  reliability  of  the  baseline  Software 

Reproduce  Tape  :=  Process:  copy  sufficient  quantities  of  Block  Change  materials  to 
accomplish  the  Field  Change  process 

Requirements  :=  Object:  documented  User  needs  that  the  Software  must  contain 

Resides  in  :=  Relationship:  "the  Block  Change  resides  in  the  Target  Compute^' 

Resources  :=  Attribute:  describes  the  SSA  Equipment,  SSA  Personnel,  Flight  Test 
Equipment,  and  Ground  Test  Equipment  needed  to  accomplish  the  work  described  in 
the  ECP 
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Results  :=  Object;  documentation  describing  the  outcome  of  ail  previous  Procedures 
Revised  Tapes  ;=  Object:  new  Product  Baseline  Software 
Revised  Manuals  :=  Object;  new  Product  Baseline  Manuals 

Rework  :=  Process;  activity  that  corrects  problems  found  during  Ground  Integration 
Test  and/or  Flight  Test 

Schedule  ;-  Attribute;  describes  the  expected  completion  dates  of  major  ECP 
activities 

Size  :=  Attribute;  describes  the  number  of  lines  of  code  Product  Baseline  Software 
contains 

Size  Estimate  ;=  Attribute;  describes  the  estimated  number  lines  of  code  that  must  be 
added,  deleted,  or  modified  to  satisfy  the  Change/Problem  Report 

Skill  :=  Attribute;  describes  the  relative  abilities  of  the  SSA  Personnel  working  on 
the  block  change 

Software  Object;  Requirements,  Design  Docs,  and  Code 

Speed  :=  Attribute;  describes  the  throughput  of  the  Target  Computer 

SSA  :=  Object:  Software  Support  Agency,  the  organization  responsible  for  Software 
support 

Standards  :=  Object:  documentation  that  describes  the  55/4 's  local  Software 
development  policies 

Stiuis  From  :=  Relationship;  "the  Block  Change  starts  from  the  Product  Baseline" 

Submits  ;=  Relationship;  "the  User  submits  a  Change/Problem  Report" 

Tarzet  Computer  :=  Object:  the  computer  that  resides  on  the  weapon  system 

Tests  :=  Object;  all  previous  Procedures,  Test  Code,  and  Results  dating  from 
development  to  the  current  block  change  cycle 

Test  A  ssets  ;=  Attribute;  describes  what  equipment  will  be  required  to  support  the 
Develop  Changes,  Ground  Integration  Test,  and  Flight  Test  processes  for  a  particular 
Change/Problem  Report 
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Test  Code  :=  Object:  the  current  configuration  of  Software  created  to  support  the 
Develop  Changes  and  Ground  Integration  Test  processes 

Test  Plcn  ;=  Object:  documentation  that  describes  how,  why,  where,  and  when  the 
Software  will  be  tested 

Test  Tape  Data:  Software  containing  the  changes  described  in  the  ECP  that  has 
completed  unit  testing 

Test  Schedule  :=  Attribute:  describes  when  all  portions  of  the  Test  Plan  are 
scheduled  to  begin  and  end 

Updated  Tapes  &  Manuals  :=  Data:  sufficient  quantities  of  all  Block  Change  materials 
necessary  for  distribution  to  all  weapon  system  bases  of  operation 

User  :=  Object:  weapon  system  operators  and  maintainers  located  at  the  weapon 
system  site 

Waiver  Board  :=  Process:  formal  organization  that  reviews  minor  Software  problems 
discovered  during  testing  responsible  for  returning  the  Software  for  Rework  or 
passing  it  through  to  the  next  process  and  generating  a  Problem  Report  to  be  acted 
on  during  the  next  block  change  cycle 
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Software  Support  Object  Diagram 


Figure  D.l  -  Object  Model 
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Software  Support  Data  Flow  Diagram 


Figure  D.2  -  Functional  Model  For  Single  Block  Change  Cycle 
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Series  Software  Support  Data  Flow  Diagram 


Product 

Baseline 


Figure  D.3  •  Functional  Model  For  Block  Change  Cycle  Series 
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Sacramento  ALC  Block  Change  Process 


Figure  D,4  -  Sacramento  ALC  Block  Change  Process 
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MIL-HDBK-347  Block  Change  Process 


figure  D.5a  -  MIL-HDBK-347  Block  Change  Process 


MIL-HDBK-347  Process 


Figure  D.5b  -  MIL-HDBK-347  Block  Change  Process 
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Appendix  E 

Memory  and  Throughput  Relationship  Derivation 


E.l 


This  derivation  was  performed  on  MathCad,  version  4.0 


Start  with  the  SYSCON  equations  from  SYSCON  Report  (pg  41)  or  Table  2.3. 

Note  these  equations  can  be  calibrated  separately  from  the  coefficient  and  exponent  if  given  the 
proper  historical  data.  Find: 


%  Timing  Fill  result  of  averaging  Design  &  Development  Coefficients  and  Exponents 


Coeff  - 


1.82+  1.82 


Coeff  =1.82 


Exp 


1.30+  1.31 


Exp=  1.305 


TimeEffecl(X)  =  Coeff  X 


Exp 


N  =20  i  =0..N 


Util  =- 
^  N 


%  Memory  Fill,  result  of  averaging  Design  &  Development  Coefficients  and  Exponents 


Coeff  = 


2.00+  1.88 


Coeff  =1.94 


Exp  = 


1.50+  1.35 


Exp=  1.425 


MemEffect(X)  =CoeffX^  N  =20  i  =0..N 


Util  =- 
'  N 
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Maximum  total  contribution  is 

TimeEffecIf  1)  =  1.82  MemEffect{  1)  =  1.94  TimeEffecIf  l)MeiiiEffect(  1  )=  3.531 
TimeEffecIf  .95)  =  1.702  MeinEffect(  .95)  =  1.803  TimeEffeclf  .95)MemEffect(  .95)  =  3.069 
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Learning  Effect  Table  2.5,  is  the  result  of  averaging  the  Design  &  Development  Coefficients  and 
Exponents  from  the  SYSCON  relationship 


Coeff  =  *  ^'*'*~  ‘  Coefr=  1.645 
2 


LeamEffect(X)  = 


Coeff 

Coeff 


N  =6 


Exp 


-.375+ -.374 
2 


i  =  I.  N  Year.  =  i 

I 


Exp  =-0  375 
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Appendix  F 
Database  Contents 
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Cotxiposite  Database 
Part  A 


Composite  Database 
Part  B 
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Composite  Database 
Navigation  &  Core  Avionics  Cat^ories 


Series  Database 
5%  Growth 


Soies  Database 
6%  Growth 
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